Splitting updates in smaller chunks to prevent headaches like the recent huge update

As many others I have been affected by the recent large update introducing many issues and bugs into what used to be a stable system.

when this happens, one can usually revert the update and wait for fixes. but this is much harder to do with such large updates containing many different packages from all walks of life.

imho it would be better to have update in smaller chunks than such a massive one. lowers the risk of things breaking and makes easier to manage maintaining a system.

it also seems to me it would be a better user experience to wait until things are sorted out before pushing a shaky update containing known bugs and issues to what is supposed to be a stable branch.
I found out several of the issues affecting my daily use happened to be known and been reported 2 months ago. it seems odd to me to ship an update containing known issues that will break user experience.

moving forwards is expected of a rolling release, but there is no need to move so fast that it will break things and push known broken and buggy pieces of software.

why the urge to update to QT 6.7 before devs even start using it ? how does this make any sense ?

Only rolling release distro will get confronted with this.
Those distro updated Qt to 6.7 before devs even started using it and Qt 6.7 introduced some very low-level behavior changes causing crashes

this was no fast move, manjaro waited very long for this step. it was announced and there are a lot of topics/threads even here in the forum that warned everyone to be prepared for “doomsday”, make a backup and to be prepared that this update is going to trouble because the changes under the hood will impact a lot. also, as user of plasma, the developers of plasma as example were demanding all the application-maintainers to update their applications but as expected a lot of them didn’t. it’s pointless to discus why they didn’t and it’s obvious that this new “era” will keep us troubled for a longer time now until we get a working infrastructure of applications back. so i already expect that the next 6-12 months will show up a lot of fails and problems that have to be fixed step by step. that’s rolling release.


Seems the number one issue was that people are not reading the instructions, especially as it relates to themes.


If you’d like more frequent updates you could switch to testing or unstable branch.

Those are updated more frequently and to some users - it even provides a more stable experience - but that is a matter of preference. Switching Branches - Manjaro

In fact the latest snap to stable was held back for a long time due to the changes implied by the major change from Plasma 5 to Plasma 6.

In fact members of this community have been pleading for a quicker release of Plasma 6 - the hype around Plasma somewhat demanded it.


Indeed. As the matter of fact, while there are normally two to three Stable Updates per month, this one took exactly two months, down to the very day. The previous Stable Update was issued on 2024.03.13, and the current one on 2024.05.13.

Also, Manjaro Testing saw many more updates, because it started with Plasma 6.0.1 being introduced, and by the time the 2024.05.13 update came along to Manjaro Stable, this was already updated to Plasma 6.0.4.

@wowo, Manjaro is a curated rolling-release distribution, which means — as @Olli says — that the updates are bundled together for a good reason. It makes much more sense to have everything properly stabilized via the Testing branch and to rebuild everything against the latest libraries and with the latest version of the compiler than to push out something half-arsed that will then need to be replaced again because of compiler changes or because it still contains too many bugs.

Also, Manjaro Stable is not bleeding-edge but cutting-edge. Manjaro takes over a lot of packages — as the matter of fact, the vast majority of them — verbatim from Arch Stable, but Arch Stable corresponds to Manjaro Unstable. From there, it then goes into Manjaro Testing, where the community can report the bugs and the package wranglers can do their thing accordingly, before everything then condenses into Manjaro Stable.

As @linux-aarhus says, if you want more frequent updates, switch to the Testing branch, but then also be prepared for more breakage.

Of course, there will always be breakage, even on Manjaro Stable, because such is the nature of a rolling-release distribution.

But indeed, most of the breakage we’re seeing now comes from the same sources as it has always come, which is that people are not reading the Stable Updates threads — or even the Testing Updates threads, which are always a good way to prepare oneself for the upcoming Stable Update — and that they are still using Manjaro as a set & forget appliance system, because that’s what they’re used to from the MS-Glassware paradigm.

But things don’t work that way in GNU/Linux, and especially not in a rolling-release distribution. And truth be told, they don’t really work that way on the commercial platforms either. I don’t use Microsoft Windows and I don’t own a Mac, but from what I hear, whenever there’s some major upgrade coming along on those platforms, there will be an equal amount of breakage, as well as some new features that cannot be removed, because the software isn’t even free (as in “freedom”).

But here’s the difference: when it comes to those proprietary systems, the users accept the breakage. They have no other choice. They’ll moan about it, but they’ll accept it, because “that’s the way it is now.” But when a similar thing happens in GNU/Linux, and especially so in Manjaro, then all hell breaks loose.

It’s not so bad over at the Arch forum, because Arch has always profiled itself as rather elitist, and Arch users are expected to be able to fix things themselves by way of the excellent Arch documentation. And in addition to that, the Arch forum’s moderators won’t stand for it.

Yet, here at the Manjaro forum, we’ve got an entirely different culture — there’s a lot more spoon-feeding going on here from the more knowledgeable and generally far less abrasive forum members — plus that Manjaro’s main web page has long carried the false claim that Manjaro would be a good distribution for absolute beginners, which it clearly is not. And as I wrote elsewhere already — and again, not so as to put myself on a pedestal — I was the one who got the webmaster(s) to rewrite the welcoming text over at the manjaro.org main web page and omit any and all false claims that Manjaro would be a suitable distribution for beginners or ideal for gamers.

Still, not everything can be blamed on the original text at manjaro.org. Not even by a long shot. We are living in a world in which selfishness, entitlement and irresponsible behavior have for decades already been stimulated — whether intentionally (so as to serve commercial interests) or unintentionally (through neglect in parenting and through influences from and peer pressure via social media).

As kind and helpful as many people within the Manjaro community are — not to mention the moderators, because you guys have no idea what we all have to deal with over here — we are seeing many of these good people burn out and turn sarcastic or bitter, exactly because of the kinds of irresponsible behavior and entitlement we’re seeing among the new members of this community, as well as any older members who only ever visit the forum when they have an issue that needs being fixed by yesterday.

Now don’t get me wrong; I am by no means implying that you (@wowo) would be such an irresponsible member, and we certainly do appreciate feedback — that’s why this forum category exists — but my point is that Manjaro is a hands-on distribution. It’s far less hands-on than Arch proper due to the Manjaro-specific tools and the fact that we curate the updates, but it’s never going to be like a point-release distribution — which includes the proprietary operating systems from Microsoft and Apple, because those follow the point-release model as well.

The Manjaro Wiki, the Arch Wiki, the Tutorials section here at the forum, and even the forum itself in general are all great resources for helping people solve their own problems, and we don’t even mind spoon-feeding on a few occasions if the member proves willing to heed advice and do their due diligence.

But if people won’t do what’s necessary — and again, Manjaro requires that — then no amount of excellent documentation is going to help. You can lead a horse to the water, but you can’t make it drink.



I beg to differ, to me when you update to qt 6.7 before even the kde dev use it, this is the very definition of going too fast.

And it turns out that this is causing several stability issues, including a crash in dolphin which caused a bug to be reported 25 times to the kde team. Despite the crash having nothing to do with KDE and being solely caused by the premature update to qt 6.7.
the current fix is to downgrade to the correct qt version: 6.6 or take care of not hovering the dolphin location bar while dragging a file until dolphin is updated to qt 6.7

The main issue about announcements is that most users do not read announcements. Than some manjaro users are not even aware this website exists, let alone the forums, or do not understand english.

Announcements and warnings are nice, but this is not a silver bullet and many users will go through the net.

Also when some forum users report that they chose to scrap their installation to do a fresh install instead of risking going through the update, this is closer to a point release than a rolling release at this point. Though this seems exaggerated and impractical to me.

But my point was not about being a rolling release or not, it was two part: first is about avoiding such massive updates by splitting them in smaller chunks to make them easier to deal with. sort of having a middle ground.
the second being about not going faster than upstream which causes stability issue to the supposedly stable branch. this hurts user trust. building trust is slow and lengthy process, destroying trust is fast and can happen in an instant, and then it is back to the starting point if not behind.

it does not seem far fetched to expect the stable branch to be stable, it seems unexpected to find out it is affected by crashes and application issues because it updated libraries version before upstream would.
imho this should remain in the testing branch until resolved. stable moving to adopting qt 6.7 a couple months down the line would not be a major issue, having the file manager crash on you multiple times a day for two months on the other hand is a major annoyance affecting the ability to work and usability of the OS.
a newcomer to manjaro installing the latest stable release to find out that it is affected by stability issues, crashes and missing functionality would be disappointed and pushed away, and rightfully so as this is not what one expects from a stable OS, even a rolling release one.


Please disregard what linux-aarhus says, he seems to be on a personal quest to being off the mark and intervene on every post I make providing inapproriate advice and wrong answers.

I have not expressed any interest in more frequent updates, switching to testing is the opposite of what I want. To the contrary I do not mind waiting longer for updates so they are more stable, I want less breakage not more. Otherwise those manjaro computers would be running arch.

Being a 100% linux user for about 20 years now, being an arch linux user for close to 15 years now, and manjaro user for the best of 9 years, having joined forum moderation teams in the mid 1990s and chose to renounce being part of moderation vowing to never return to it by the late 2000’s, I am familiar with almost all of what you said here.

As mentioned above I am aware that most people do not read the announcements and forums, but some have no business doing that, which I can attest as I provide support and maintenance to regular non technical non english folks.
myself being a technical user, I am sometimes guilty of not reading the announcements for a variety of more or less valid reasons ranging from lack of time, trusting my ability to fix things if something goes wrong, being biased due to a history of updates causing no particular issues, etc.

But as I said earlier this is not about turning a rolling release into a point release or misunderstanding what a rolling release is.

This is about avoiding huge updates such as the last one which are really time consuming to sort out and revert when things go wrong to that point. Let alone when like myself you have a dozen non technical manjaro users coming to you for help and support once the update went bad and broke their system that rely on for their daily life from keeping in touch their grand children on the other side of the planet to paying taxes, and managing medical appointments.
rest assured that this is not a rolling release issue as this also happens with people on ubuntu or even debian once in while.

I’d rather spend the evening with my family after a simple revert of the problematic update chunk than having to spend hours going through a massive update of thousands of packages to identify which ones can stay which ones have to be reverted because they are part of the group causing the issue.

My main contention with what you said is that I disagree everything had been properly stabilized in testing to be released to stable. I’ll use the same dolphin example again.
when a library version discrepancy due to premature adoption of the latest version before the dev start using it, is causing a crash in the application each time a file hover over the location bar in the file manager, this is not properly stabilized to me.
According to other reports in the forums, it seems I am not alone thinking that there was no rush in pushing plasma 6 to stable right now, and it would have been better to wait a little longer for things to be more stable before pushing to stable.

I mean either testing was not thorough enough and missed some quite obvious issues, or people in charge knew about those stability issues and chose to release anyways. but either way imho this an unexpected shortcoming from manjaro who had me accustomed to better.

Of course this may be on me for mistakenly having the impression that manjaro would be aiming for and succeeding at being stable enough to be appropriate for daily use and work while it had been a side effect all those years, but I beg to differ as at least to me manjaro has done an excellent job being my main os on my work laptop for 8 years now. and I do not remember a previous occurrence of such a massive update breaking so many important things in a daily workflow. maybe I am biased due to having a sidux powering my work laptop, before switching to arch and then to manjaro as maintaining arch on a work laptop was eating too much time too often.

Don’t worry though, my manjaro work laptops are unaffected by the move to plasma 6 as one has not received the update, and the other has had the update reverted to the previous vorta snapshot the minute I saw the mess as I cannot afford to have a dull blade replace my sharpened saw.

Ask the Arch Linux maintainers. Manjaro is an Arch-based distro so most of the packages come straight from there. Manjaro basically adds on top of that an easy installer, some QoL changes, and the delayed updates.

So it’s not a decision that was made by Manjaro, and if you don’t like what Arch Linux does then don’t use an Arch-based distro. I don’t mean to appear rude but it really is that simple.


This isnt manjaro, and I doubt they even realized the descrepancy.

The QT version, along with the Plasma version, are from Arch.

Manjaro held it for a while on Stable and put on overlay on plasma-workspace to default to x11, but otherwise didnt really change anything, but certainly waited a long while, and then served the plasma+qt as it was received from arch.