Q: how **does** one "solve"/prevent updates breaking shared libs expected by other apps not in AURs? Only update once a quarter or year?

So yesterdays broken ungoogled-chromium (by something or other updating icu) got fixed by the chromium pkg also being updated some hours later. So far so neat! And merci!

But not all software is in AURs. Say you run Unreal Engine 5 editor well for days. Some dozen-or-so pkg updates come in this morning, all referring to vulkan and/or mesa and/or GL. Next thing you know, UE crashes on start like so:

0x00007f6357d006cb libnvidia-glcore.so.545.29.06!UnknownFunction(0xd006cb)
0x00007f6357d36101 libnvidia-glcore.so.545.29.06!UnknownFunction(0xd36100)

So you send them a crash report, but that solves nothing for weeks by itself. OK, you can “downgrade a package” but there was a dozen or so. What you really want is “rollback this ‘Update’ I did (via discover, as the Updates tray icon opens it) — let me select it and it covers the packages-selected-during-that-one-operation”, and those get downgraded to before. They all came as one.

Is there a way of doing that? And why do get “old” libs deleted or overwritten willy-nilly. Everything worked fine before that update or rather, some-or-other of those dozen-or-so pkg updates within that one Update operation I recklessly risked.

Just trying to learn how people keep their system stable. I can actually be fine with running software updates just once a year (browser once a quarter) once it’s all stably running, but is there another way? Snapshots are fine for “updates broke system into unbootable state”, but just a simple “undo this update” would be real neat, if possible. Is it?

Update: similar issue occurs for all kinds of games, it seems. So probably will get fixed eventually. Will monitor that thread. And then… no more updates ever :laughing:

The first thing I would say is that these are (part of) the risks inherent in a rolling distro.
Secondly, they are one of the reasons why one should use Arch packages as much as possible (where possible). The maintainers take care of everything else.
Where this is not possible, one should try to rely on AUR packages. Here it is more possible for their maintainer to be a bit ‘late’ in updating, but in my opinion comments are received faster than issues on upstream sites (where the audience is much larger).
In my opinion, none of these should be a barrier to the continuous (garuda-)update of the system.
Rolling releases are a horse that must be tamed and ridden! :slight_smile:

4 Likes

Ah I forgot to mention I was on non-Arch rolling distro for 6 years, super stable. Rolling, but not bleeding haha. That stability must have been a mix of the severe lagginess in adopting updates, xbps, and their dictatorially-defensive automated repo policies / checkers etc.

Doesn’t matter now since this new machine’s NVIDIA setup here didn’t fly with that distro whereas Garuda delivered here.

Well right now I’ve rolled back and know the list of updates on offer in the Systray breaks UE so I’ll just let them sit there until… I dunno, maybe always time it with UE5 minor releases. :grin:

Secondly, they are one of the reasons why one should use Arch packages as much as possible (where possible). The maintainers take care of everything else.
Where this is not possible, one should try to rely on AUR packages.

I this what Octopi’s Tools / Repository Editor refers to? That one checkbox-lists garuda, core, extra, multilib, chaotic-aur, custom. All currently ticked. How can I say “Arch packages only”, if those are indeed a separate/more-official category from all AURs?

That’s hardly a rolling distribution, unless you mean rolling-down-a-hill. :slight_smile:

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.