Comment by baghira | Hacker News Reader

Comment by baghira | Hacker News Reader

Parent Full thread

To be clear: I also am an Arch user (albeit not exclusively). I'm not complaining about the bleeding edge part (from your answer I get the feeling you already had similar discussions, with people complaining "upgrade X broke my system"). What i was driving at is the fact that pacman, as it is, does not cover the whole use case of other distros.

Would you take debian, with its three branches, and move it to pacman? No, because the lack of pinning and differentiation between security upgrates and normal upgrades would wreak havoc ("get a better upstream" is a nice suggestion, but an unpractical one). The same could be said for Fedora (actually, for Red Hat, but Fedora is Red Hat testbed after all).

I could set up my own repository, clearly, it may very well be a good solution, but to me that is not automation anymore. Similarly, there is nothing preventing one from setting up one's own repo of old packages, and reinstalling those. Still, I see the value in having the rollback features inside DNF (call it laziness, if you wish). I guess my comment came out as random pissing on Arch, when what I wanted to point out was that other distros simply have different needs.

You can pin packages in pacman, you just add them to the IgnorePkg list. And while pacman does not have a native rollback command, it does not delete any historical version of a downloaded package by default - you can set it to delete, say, 3 versions and older if you want. But you can just reinstall an old version and blacklist the package until its fixed if something goes wrong.

And that kind of operation could be automated - its just a pacman -U on the old version and append into pacman.conf on the IgnorePkg line.

And nothing really stops you from having, with pacman, repos the way Ubuntu does - because really, its not that security and feature updates are hugely segregated - they usually are just a boolean in the package description. What happens is they have repositories of software they will not update with feature releases but instead only ship bugfix and security patches for, and they just call them jesse / wheezy / vivid / wiley etc. You could use pacman for the same end, making a repository of software you don't push feature changes to but just push bugfixes in, and again replace Archs repos.

The point I'm trying to make is there is a distinction between Archlinux the repository and Pacman the package manager. You can get around a lot of the unfavorable aspects of how Arch does packaging by doing it yourself. Of course it makes no sense to actually do that when Debian, CentOS, and Ubuntu LTS exist to do that exact same job without all the work, but it isn't because pacman is crippled in one aspect of package management to such a degree its unusable for that purpose.

We are basically agreeing. The point is not that you cannot automate pacman, but rather that other package managers automate for you, which is bound to be a virtue for some people. I personally never found the "integrated" rollback in dnf/yum particulary useful, but I've heard of enough people who used it to accept that it is a desired feature. Same goes for "dnf config-manager" for managing repositories with one command.

As far as pinning goes, however, I disagree: if you mark a package as IgnorePkg it does not get updated. You could use either naming conventions or splitting the repos up to track different repos for different packages, but it starts looking like an antipattern to me (i.e. the way you would have firefox track jessie while you are on wheezy would be by setting up your own repo only for firefox, a bit of an hassle). It's fine if you are the packager, it's a bit cumbersome if you want a stable debian box with a fresher version of django and nginx.

After all the road map for pacman 5.0 proposes hooks and a better handling of optdepends. Both can be already automated via scripts, but both would be nice to have out of the box.

Reply on news.ycombinator.com