4 ms·

I have the similar experience to the OP. The last time I had 700 packages or so updating, pressed Ctrl+C (apt or brew never left my system in a broken state aft

I have the similar experience to the OP. The last time I had 700 packages or so updating, pressed Ctrl+C (apt or brew never left my system in a broken state after Ctrl+C) and the system no longer worked after reboot. Had to update all packages via a bootable Arch image on a USB to fix it. Also had KDE and Gnome behave weirdly after update to the point of having to reboot immediately – never happened on Ubuntu LTS. Arch is amazing as long as everything is fine but if you do something wrong, it’s far more fragile. I guess it’s ok for a pro user distro but my servers will remain on Debian. Also, I had Arch on an old laptop I use from time to time and it happened at least a few times that if I did not turn it on for 3 months or so, the system was no longer upgradable.

spinax 5y ago
> I had 700 packages or so updating You absolutely ignored your Arch system for far too long and most likely missed important News notifications that manual actions were required, it happens now and again. With updating 700 packages at once you've just dug yourself a hole - Arch is not a system you can ignore for that long, by design it's always changing to reflect the newest upstream changes to software. As I posted to the other person, if you want a distro to ignore over time then Arch is not for you.
- pxc 5y ago
  Imo this is a lame excuse. Some rolling release distros whose packages more or less equally up-to-date are far less brittle, namely NixOS and openSUSE Tumbleweed. Arch's demanding nature with respect to being routinely updated follows directly from the fact that its package manager is stateful and unsophisticated (e.g., its dependency resolver is incomplete (will fail even when solutions are available, because dependency resolution is NP-complete and 'gotta go fast')). It's totally fair to call this an Arch/pacman defect. Part of it is also lack of enduring hacks like Debian and derivatives use (long-lived transitional packages), which is a choice by Arch developers. A glance at the online Arch package listing and some example .PKGINFO files indicates that Pacman also doesn't support metadata like 'provides' and 'replaces' in DEB and RPM, which means the developers have fewer tools at their disposal for dealing with transitions like that, even when they want to. Clearly many users don't mind all these tradeoffs, but others who shy away from Arch after experiences like that mentioned in the GP comment are totally right, as a matter of fact, to blame the design of the package manager for their woes. We're not looking at the price of bleeding edge packages or a rolling release. We're looking at the price of 'keep[ing] it simple, stupid'. Edited to add: the existence of the DUR shows that Debian probably doesn't fall on the right side of the complexity tradeoff for the purpose of maximizing user contributions. The same users who contribute to it could also create their own Debian packages, but they don't, presumably in part because it seems harder to get into. (It's not that bad if you use debhelper, but it is also clearly a crufty system that has evolved this way and that over time.) So Arch's philosophy also clearly has other strengths. But imo we shouldn't give it a pass on the kind of fragility outlined in the GP.
  - bscphil 5y ago
    > A glance at the online Arch package listing and some example .PKGINFO files indicates that Pacman also doesn't support metadata like 'provides' and 'replaces' in DEB and RPM, which means the developers have fewer tools at their disposal for dealing with transitions like that, even when they want to. I guess this is what you get for making assumptions about a platform you're technically unfamiliar with, isn't it? https://wiki.archlinux.org/title/PKGBUILD#Package_relations https://wiki.archlinux.org/title/PKGBUILD#Package_relations
seba_dos1 5y ago
So, in other words, you have intentionally tried to break your system and you succeeded. So, congratulations? pacman and apt have a different feature-set. Handling a neglected system and recovering from terminated upgrade are explicitly not what pacman does. If you expect such features from your system, why did you install Arch in the first place?

spinax 5y ago

> I had 700 packages or so updating You absolutely ignored your Arch system for far too long and most likely missed important News notifications that manual actions were required, it happens now and again. With updating 700 packages at once you've just dug yourself a hole - Arch is not a system you can ignore for that long, by design it's always changing to reflect the newest upstream changes to software. As I posted to the other person, if you want a distro to ignore over time then Arch is not for you.

pxc 5y ago
Imo this is a lame excuse. Some rolling release distros whose packages more or less equally up-to-date are far less brittle, namely NixOS and openSUSE Tumbleweed. Arch's demanding nature with respect to being routinely updated follows directly from the fact that its package manager is stateful and unsophisticated (e.g., its dependency resolver is incomplete (will fail even when solutions are available, because dependency resolution is NP-complete and 'gotta go fast')). It's totally fair to call this an Arch/pacman defect. Part of it is also lack of enduring hacks like Debian and derivatives use (long-lived transitional packages), which is a choice by Arch developers. A glance at the online Arch package listing and some example .PKGINFO files indicates that Pacman also doesn't support metadata like 'provides' and 'replaces' in DEB and RPM, which means the developers have fewer tools at their disposal for dealing with transitions like that, even when they want to. Clearly many users don't mind all these tradeoffs, but others who shy away from Arch after experiences like that mentioned in the GP comment are totally right, as a matter of fact, to blame the design of the package manager for their woes. We're not looking at the price of bleeding edge packages or a rolling release. We're looking at the price of 'keep[ing] it simple, stupid'. Edited to add: the existence of the DUR shows that Debian probably doesn't fall on the right side of the complexity tradeoff for the purpose of maximizing user contributions. The same users who contribute to it could also create their own Debian packages, but they don't, presumably in part because it seems harder to get into. (It's not that bad if you use debhelper, but it is also clearly a crufty system that has evolved this way and that over time.) So Arch's philosophy also clearly has other strengths. But imo we shouldn't give it a pass on the kind of fragility outlined in the GP.
- bscphil 5y ago
  > A glance at the online Arch package listing and some example .PKGINFO files indicates that Pacman also doesn't support metadata like 'provides' and 'replaces' in DEB and RPM, which means the developers have fewer tools at their disposal for dealing with transitions like that, even when they want to. I guess this is what you get for making assumptions about a platform you're technically unfamiliar with, isn't it? https://wiki.archlinux.org/title/PKGBUILD#Package_relations https://wiki.archlinux.org/title/PKGBUILD#Package_relations

seba_dos1 5y ago

So, in other words, you have intentionally tried to break your system and you succeeded. So, congratulations? pacman and apt have a different feature-set. Handling a neglected system and recovering from terminated upgrade are explicitly not what pacman does. If you expect such features from your system, why did you install Arch in the first place?