I doubt there would be much of a dependency issue for Dolphin 25.12.0 vs. Dolphin 25.12.1.
Also, I was not referring to Dolphin in particular, but packages in general. The whole ‘only a single version’ approach takes some getting used to.
In this case, it would be alright, I guess.
Well, there is some wiggle room, but it’s all really package-dependent. Some packages can easily be replaced by a different version number, but others are more finicky.
That may be.
Do you know which of these dependencies caused the issue?
$ pamac info dolphin
...
Depends On : baloo baloo-widgets gcc-libs glibc kbookmarks kcmutils kcodecs kcolorscheme kcompletion kconfig kconfigwidgets kcoreaddons kcrash kdbusaddons
kfilemetadata kguiaddons ki18n kiconthemes kio kio-extras kjobwidgets knewstuff knotifications kparts kservice ktextwidgets kuserfeedback
kwidgetsaddons kwindowsystem kxmlgui qt6-base qt6-multimedia solid
...
Many of the dependencies was updated as well.
But yes - you can pull the latest dolphin from Manjaro unstable branch - but there is no guarantee the action won’t generate other issues
sudo pacman -U https://mirror.easyname.at/manjaro/pool/sync/dolphin-plugins-25.12.1-1-x86_64.pkg.tar.zst
Sure you can try that…
Though as I pointed out earlier in the thread, it’s really an extremely minor issue easily sidestepped for a while - you can also avoid it by simply watching out for selections.
The Golden Rule is always to keep the system in a supported state - fully synchronised ( sudo pacman -Syu).
However, following this, you can choose to downgrade, or do whatever you wish - just make sure you have a snapshot to wind it back.
By trying it, you could let us know if you discovered any breakages - but part of the reason Manjaro has a reputation is that many users misunderstand the model of treating the system as a whole - forcing unsynchronized changes.
The risk is pretty universal to any kind of Linux release - it’s part of the reason I got frustrated with Mint - and sometimes the mess got so bad that I had to resort to a clean install to clear it up.
So yes, your statement is incorrect in it’s implication - but remember, if you upgrade Dolphin it will expect the newer libraries than Manjaro’s repos provide.
Your best plan, by far, is to switch the branch until the issue is cleared in Stable - or just stick with Stable and avoid the issue.
Give it a try:
sudo pacman -S unstable/dolphin
Let us know how it goes 
but pacman will try to install required dependencies too… it’s a partial upgrade, and unless you wind it back with testing, your guarantee will be invalidated (you have to pay again to get a fresh guarantee).
Sometimes it’s possible to fast-track an individual package; one that perhaps isn’t directly affected by versioning and the current state of other dependencies; but, this is only determined on a case by case basis.
It’s a forgone conclusion that (most) packages provided as part of Plasma (such as Dolphin) will have KDE underpinnings. Likewise, other packages will often have dependencies that demand version-specific consideration.
Occasionally, someone might ask that a package be fast-tracked or promoted to Stable if, for example, it’s already in Testing and has no dependent issues – under those circumstances the request might be granted, provided that it’s practical.
If fast-tracking of a package isn’t possible, the option remains to switch branches as already mentioned.
I understand the frustration that may have led to that comment, but I’m fairly confident you’re aware that these practices are in place to help prevent breakages in a rolling release distribution.
Aside:
Speaking generally, some tend to ignore the implications of not following recommended guidelines, and end up “breaking things” themselves – these same users invariably blame Manjaro for “not getting it right”. 
Related:
For users who rely on software built via the AUR, switching to the Unstable branch is already a recommended option, because that branch is the closest to Arch Stable.
That was just an observation, nothing more. I’m actually more surprised than frustrated, if anything.
I guess I’m just used to approach things differently after decades of working with Gentoo (both as user and developer). There, you’d simply pull the diff that fixes the bug, put it in a certain folder, rebuild the package and call it a day. Or unmask the newer version of the package and update to that. No quirks, no repercussions, nothing fancy or out of the ordinary at all.
I switched to Manjaro to have more time for the important things in life, now that I’m retired. Which worked out for the most part - to me, Manjaro is like a sanely preconfigured Arch, providing a nicer out-of-the-box experience. But at times like this, I do miss the flexibility that Gentoo offered. Who knows, I might switch back one day.
@linux-aarhus, @Ben, @Aragorn Thanks for the advice, much appreciated. I’ll give it a try.
4 Likes
I recall some 15-20 years ago trying to navigate the portage system and finally install Gentoo – for whatever reason, I gave up on that.
However, I’ve always appreciated the benefits of using a non-derivitive OS; one of the reasons I use Debian as opposed to the 'buntu and such.
Arch was an inconvenience (for me) and Manjaro was like a breath of fresh air in so many ways. Perhaps I’m fortunate to have settled on AMD a decade ago, as I’ve had no problems that weren’t easily attributed to my own inattention.
2 Likes
There is a very steep learning curve to it, there’s no sugarcoating that.
I remember the endless discussions within the team whether there should be an official installer or not. The reasoning of the ‘old guard’ was that it should be difficult to install to make sure users familiarize themselves with the inner workings of their machines beforehand (or along the way). Same with Arch, I guess.
While certainly a valid point, I (amongst others) argued for a long time that times have changed. Setups have become way more intricate (UEFI, Secure Boot, Encryption, multiple DEs, etc.) and users still have to spend lots of time on customization, which provides plenty of opportunities to learn, thus installing should be quicker and less painful. Well, I imagine those discussions are still raging…
Also, during the time frame you mentioned, it was actually quite difficult to keep installations stable and updated over a longer period of time. Almost each and every update run had the potential to render the system unusable. Thankfully, that’s no longer the case nowadays, Portage and its tree became rock-solid over the past 10 years, give or take.
3 Likes