Conversely, `pacman -Syyuu` doesn't complete reliably without user intervention, which is far from ideal. I say this as an Arch user - the expectation that I'm going to manually attend to package upgrades in practice leads to me using outdated packages

I'm genuinely curious about this, as I see people say it a lot but it's not my experience at all.

I have an Arch Linux desktop (KDE + AMD), I update it every few days, and it's always fine.

I also have a shell VM that runs IRC etc that often isn't updated in months, and I run `pacman -Syyu` and everything works fine.

I've never had the infamous 'Arch updates are unreliable' issue. Is it certain packages that are more prone to it, or something?

Yeah, `pacman -Syyu` works fine most of the time, except when you use a lot of AUR `devel` packages, which can break because they often do not have strict dependencies definition.

AUR packages are not part of the distribution though, so that's understandable - they're explicitly user contributed packages and are very much "here there be dragons" and "if it breaks, you get to keep both pieces".

Agree

I haven't had it often but I've had stuff break sufficiently badly that I couldn't boot to a graphical environment before.

I agree with the other posters that a lot of the stuff that breaks is in the AUR, but practically most users rely on the AUR so if the AUR is prone to breakage so is the typical user's arch Linux environment.

I'll also freely concede that part of this stems from the common practice of treating the AUR and pacman packages interchangeably through helpers, but that's a practice that's almost necessary for reasonable use and is present on the official wiki.

I think ultimately Arch is just a UX which was designed in a simpler time when users could reasonably expect to account for all the packages they installed

>> but I've had stuff break sufficiently badly that I couldn't boot to a graphical environment before.

Is there some "restore to previous state" (Windows-style) feature for that case? Because I'm too afraid to install Arch on my only working PC.

It's probably because you run updates every couple of days that you don't have the issue. For me, I have a laptop that can go untouched for up to a month, and it's not fun catching up on a month's worth of updates. Lots of packages have been replaced, I usually have to futz with the keyring, etc.

Also worth pointing out - the fact that you can so easily perform a partial update with pacman and totally break your system is infuriating to me. If an upgrade fails, it should revert to a cached package database. Otherwise an update will fail, the user will go to install something else, and all of a sudden nothing can link to libcrypt because you installed ntpd, which upgraded all of your auth stuff after an openSSL vuln was discovered, and everything is hosed.

I do have a shell VM (accessed via SSH & xpra) that I update much less frequently and still don't have issues.

I think the main reason I have fewer issues compared to other comments here is I try to minimise my use of the AUR, and don't install third-party repos.

> If an upgrade fails, it should revert to a cached package database.

I'm prettttty sure it does now? When did you run into this problem? It definitely used to be a problem, a long time ago (I ran into it once when I ran out of disk space mid-upgrade), but I think system updates are atomic now.

Happened to me a few months ago (whenever that big SSL 0-day was announced).

I use a 3rd party repo for ZFS drivers, which gets checked for compatibility with each new kernel release by the maintainers, so ZFS frequently stops me from upgrading, and crucially it stops me after I've already fetched the new package databases.

Running pacman -Sy and then installing an individual package isn't supported and it's understandable why.

Running pacman -Syu and having it break sticks you into this limbo where if you install anything before finishing the upgrade, you risk shooting yourself in the foot.

Interesting! How does the ZFS upgrade "stop" the package upgrade process, I wonder? Might be worth reporting a bug, maybe pacman can handle that kind of failure better, or maybe the ZFS package could be changed to fail more gracefully. I think the pacman devs would agree leaving the system in a partial-upgrade state is a bad thing to do.

It's not a bug, it's intended behavior.

The official release of ZFS on Linux I believe only supports kernel 5.x. Since arch is always on the cutting edge, the repo maintainers need to manually test the driver with each new kernel release before pushing it out to the world. They stop you from borking your system in the interim by having a strict version requirement for Linux on the zfs package. Pacman only does that check, though, once the -Sy operation has finished

Ohhh, I see what you're saying. Yeah, that is a tricky corner case :-/

I think it depends on when folks were using Arch. I've been using it since 2007, and back then before the "conf.d" configuration file convention became common, it was very frequent that you would need to manually merge your local config files with the upstream one. If you screwed up or forgot, your system would be some variety of hosed. It's become much, much less common in the past ~10 years. I'd hazard a guess I only have to manually attend to an update once or twice a year now, where it used to be almost daily.

Ehem: https://old.reddit.com/r/EndeavourOS/comments/wygfds/full_tr...

EndeavorOS is basically vanilla arch with an installer, I just posted their thread because they were open and transparent about the issue while the arch sub did very little.

When I raised this with an arch dev, I was told they purposely shipped grub's master branch (not release) because they didn't feel like backporting a security fix, and if I couldn't fix a grub issue with no working computer I probably didn't have any business using arch.

Ok then. Went and downloaded popOS from a friends house and haven't touched arch since.

I may be misreading this comment, but it feels a little stuck up. Arch is created for Arch developers. This is well-known and they have never hidden that. The wiki states as much somewhere in the installation guide. That the distribution turned out to be useful to many others is purely coincidental. If you tried it and decided you're not one of them, no need to pour shit on devs as if they owed you something and didn't fill their part of the bargain.

I agree, it is a little stuck up, on the part of the elitist devs.

If this was a little hobbiest distro, I'd agree with you, but this is one of the most popular distros out there. There is a certain expectation of competency and quality.

I would argue that shipping the master branch of a bootloader isn't competent when there are stable releases available, and not addressing the issue when literally thousands of users are having the problem isn't very respectful of your userbase.

FWIW, I did eventually fix it, but the endeavour os folks were much more understanding and helpful with the issue. The arrogance I saw on r/arch was insane and offputting.

> I've never had the infamous 'Arch updates are unreliable' issue. Is it certain packages that are more prone to it, or something?

Liferea is currently broken as of the latest update 5 days ago due to https://github.com/lwindolf/liferea/issues/1217

I also suffered from the grub issue mentioned here elsewhere, had to rescue my laptop after it became unbootable (though it was very simple to Google the problem and to fix it). I don't think using grub is particularly unusual choice in packages.

I also had to downgrade Samba and wait a couple of weeks for a fix to a bug it had mounting password protected shares. Again, Samba isn't exactly an exotic package.

Also had to downgrade something in my audio stack (I forget if it was pipewire, pulseaudio or a kernel issue that was the root cause) and wait a couple of weeks for a fix due to bluetooth issues.

There's also the occasional update that requires manual intervention.

All of that said, I don't think I cumulatively spent all that much time on maintaining my Arch systems as all these errors are spread across a long period of time and didn't take that long to handle. I probably spent a lot more time and nerves on Ubuntu as I don't think I've actually ever had a dist-upgrade work flawlessly and each time takes a lot of effort and mental energy.

Those are all upstream bugs, not Arch's. That's the trade off when you're running bleeding edge, but you can't blame Archlinux for packaging a buggy application.

I'm no really blaming anyone, I'm thankful for Arch, I love it, and I recommend it to other people who ask (well, at least those that can handle it :)).

> Those are all upstream bugs, not Arch's.

IIRC the grub issue was in the update script, so it may have been an Arch bug rather than an upstream bug?

Still, it would also be nice if a package is known to be broken due to an upstream bug it would get rolled back, so once the breakage is known, no one else will update into a broken state. That would save some time over each person individually updating to a broken state, debugging for a bit and then downgrading the broken package and then also paying attention not to reupdate it each time they update the system until the problem is resolved.

But again, not trying to complain or assign blame, I was just responding to a question in a parent comment.

You might enjoy Void Linux - its package management story is similar to Arch, except that updates invariably work.

Ubuntu has a much more aggressive 6 months release cycle, it's not nearly as outdated as Debian sometimes can be.

But that means I have to update my OS and my application when I want a new version instead of just my application. Say what you want about Windows, but I can download and run the latest version of all my applications on Windows 7 without it missing a beat.

Yes, because either you, the user, must track down .NET Framework X.Y (less of a problem now that they're stabilized) or because the application packs all of it dependencies and shoves them into \Program Files or \Windows\System32 until it's eventually 30gb with 1000 copies of msvcpXXX.dll

That's not that different from the distribution model of Flatpaks/AppImage (or APK, or .app on MacOS/iOS). It's more that, traditionally, Linux packaging solutions try to only have ONE copy of glibc or any other library, and packages are recompiled from source so the symbols resolve. Something which isn't an option on Windows, as a generality.

I don't think Windows is a good comparison, since major upgrades for it tend to be vastly more invasive than major upgrading the average Linux distribution. Debian 6→7, ten years ago, was a really massive infrastructure upgrade, but ever since it's been pretty smooth sailing. Ubuntu is a bit bumpier, but it's still only on the level of Windows' "major feature upgrades (that totally aren't service packs because we don't want to extend your warranty)" updates that Windows 10 and newer get every 6 months.

And Windows 7 is extremely old and only works with new software because, and as long as, developers go the extra mile to make their software work with its old APIs. Valve recently announced that they'll drop support for it next year, and other companies will follow soon. It's not too much different from the situation of, say, Debian Oldstable or Ubuntu LTS: Outdated, but popular enough that people tend to put in the effort anyway.

Hackers can also run their applications on your Windows 7 installations without missing a beat

Is that true?

Without having looked closer at how to build either of snap and flatpack; if you can static link or bundle libraries with your snaps/flatpack packages, what stops you from doing the same in a .deb?

It's just a convention not to, no? IIRC the Steam .deb comes with pretty much everything statically linked. Works fine.

It's called stability and it's a good thing. And no, nobody is forced to use docker.

But what's the point? You install debian stable, where every library is at around 2 years old. Now you want run SomeApplication (Blender, Gimp, video games) as that's what you actually use your computer for.

If you wanted to run a 2 year old version of SomeApplication, that would work just fine. Is that what you really want? Is that what most users want?

If you instead install a snap/flatpack of the latest version of SomeApplication, you are installing also new libraries instead of the good old stable libraries your distro provides. So what's the point then?

> that's what you actually use your computer for

No, you use Debian stable for servers, embedded, and anything production-related that has to be stable.

You use Debian Sid for your playground or hobbies and it will be just as up to date as every rolling distro.