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 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
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.
> 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.
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
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.
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.
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 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.
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".
