Hacker News Reader

Comment by zanny | Hacker News Reader

I like it way more than apt at least. I don't have to use apt-cache, apt-get, apt-kitchensink to do what I want. Its all just subcommands of pacman. Its like vim vs nano - the later has the commands in the shell, but they aren't nearly as fast or power to use as vim if you take the time to learn it. Ironically, I use nano most of the time because I'm not terminal-locked enough to get vim muscle memory, but I use pacman enough to remember everything.

Zypper is actually fairly good. Still way more verbose than it needs to be, but it seems like a fair compromise between "apt-get stupidly-oversized-function-name" and "why the fuck does -Sy mean grab updated package lists from the repo".

View on HN

Syntax isn't really the problem, given that one could easily write a wrapper around pacman, or apt-get, or dnf/zypper (at least for the subset of common operations supported by all). The problem with pacman as a package manager is that it simply does not have the features needed by fedora or debian. With the infrastructure given by Arch there is basically no way to have automated upgrades without potentially breaking the system. The same goes for the AUR: it's great when you know that the user is reading the script and making sure it's not malicious: it's not a model that scales for server (just like FreeBSD ports do not cut it if you have lots of machines), or if you imagine 10% of the computer running Arch (malware bonanza). Still, automating apt-get is messy (and here dnf/zypper do a better job) and building .deb packages and setting up your own repo is too complicated.

Arch always posts breaking changes to its mailing list. If you are complaining about the bleeding edge part, that really has nothing to do immediately with pacman as a package manager, you could always pull a Manjaro with real package introspection to keep tabs on incoming software.

The only real missing piece of pacman is that there is no distinction between a feature and security / bugfix update. But then you should be more stringent with upstream to beta test their feature releases better.

Really if you wanted to automate pacman nothing stops you from creating your own custom repo as a gateway to some workstation or server cluster you have and setting it up to use your custom repo exclusively for all packages. It has delta support, does checksums, uses the best compression format available, and is a lot easier to use for custom applications than the OBS or alternative packaging tools.

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.

Yes the `-Sy` bit is a bit cumbersome / annoying. I would have much preferred `pacman update -s` and `pacman remove <package>`.

When I have to install a font on my machine that isn't in AUR I'll just roll up a PKGBUILD, install it and dust my hands off. Makes it incredibly easy to remove the packages later if I no longer need them.

Its not cumbersome, the alternative is more cumbersome, it just requires memorization. Like I said, zypper is a great compromise, where you could do zypper update and zypper install, or you could do zypper u and zypper i. A bit more intuitive for the newbie but it doesn't make you write words like you're writing a poem in bash.

You can also use `aptitude`, available on both Debian and Ubuntu. It addresses your complaints and it's the first package I install.

It gets so incredibly slow when you have aptitiude around apt around dpkg. Its a minor complaint, but when pacman does everything I want and is probably a tenth the codebase of either yum, zypper, dnf, or apt, then I'm content.

I don't think aptitude is built around apt, but even so, I haven't noticed performance issues.

Since apt-1.0 (basically, since jessie), there's also apt(8), which integrates (most of) apt-get and apt-cache.

Thank you! I had no idea it existed

Huh, I had it installed and had no idea about it. Looks good :-)

https://pypi.python.org/pypi/apt-wrapper

Reply on news.ycombinator.com