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.

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

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