2 ms·

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

by 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

by spinax 5y ago

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