[DivineBicycle]

Have you ever tried pacman? I’ve used pacman, zypper, dnf, apt, and apk (a few times), and found that (for me) pacman is the best, with its flags, while not making sense to a beginner, are very versatile, e.g. -Syu (sync and update all packages), -Rsn (remove a package and all its dependencies unneeded by other packages and its config files), etc. apk might be a tad faster, but I’ve found pacman to be much faster than dnf, although I can’t remember exactly how fast zypper is since it’s been a few months since I used OpenSUSE. PKGBUILDs are also a great part of the pacman system, and while I’ve not written any yet myself, I can mostly understand what they are doing, and I’m fairly sure I would be able to write one if needed, whereas when I tried to write an RPMspec (? might have gotten that name wrong) I gave up after an hour of trying.

[pxc]

> Have you ever tried pacman?

I have! I'm personally not a fan. I've generally experienced pacman as incomplete, brittle, and clunky.

For me, giving up the speed of pacman for the robustness, flexibility, nicer CLI, and feature completeness of dnf or zypper is an easy tradeoff to make.

> I’ve found pacman to be much faster than dnf, although I can’t remember exactly how fast zypper is since it’s been a few months since I used OpenSUSE

Compared to pacman, zypper is slow like dnf— probably slightly slower.

> PKGBUILDs are also a great part of the pacman system, and while I’ve not written any yet myself, I can mostly understand what they are doing, and I’m fairly sure I would be able to write one if needed, whereas when I tried to write an RPMspec (? might have gotten that name wrong) I gave up after an hour of trying.

It's been a long time since I ran openSUSE on the daily, but when I did I managed a repo of RPM packages and I'm pretty sure I created at least some of their spec files from scratch, although most were downstream forks or packages I imported from elsewhere.

I don't know what made it click for me, but I found it a little easier than DEB packaging (maybe in part because I learned it later), and definitely manageable.

But I hear you: PKGBUILDs are widely praised for their simplicity, and it clearly helps a lot of people make good use of the packaging system. That's a real strength.

[DivineBicycle]

> incomplete, brittle, and clunky.

I don’t see where you might experience incompleteness in pacman, although I might see how you could experience it to be clunky. Do you mind humouring me and explaining this further?

> flexibility

I’m also not sure where dnf is more flexible, although I probably never explored it fully. What do you find about pacman to be inflexible?

> nicer CLI

This I most definitely understand. Even after over a year of using pacman I don’t try to understand why flags are named what they are (looking at you —-Sync), but having memorised them I do quite enjoy pacman.

> I’m fairly sure I created at least some of their spec files from scratch

It could just be my low intellect manifesting itself I suppose, so next time I have a Linux install using rpm I’ll try again.

Thanks for replying to my questions, it’s always interesting to hear from Linux veterans!

[pxc]

> It could just be my low intellect manifesting itself I suppose, so next time I have a Linux install using rpm I’ll try again.

No, I think I have a high pain tolerance for Linux stuff in general and packaging stuff in particular. I got into Linux before I started high school, and Linux package management immediately struck me as something beautiful, powerful, and almost magical at that age. That sustained fascination has meant that I can tolerate different learning curves in that domain than in others.

Additionally, by the time I started messing with RPM packaging, I had already packaged for Gentoo, Arch, and Ubuntu, so I think I had already developed some intuitions for how to explore packaging systems and their documentation.

> I don’t see where you might experience incompleteness in pacman, although I might see how you could experience it to be clunky. Do you mind humouring me and explaining this further?

Tbh, here I'm probably holding old shit against Pacman that no longer applies. But when I daily drove Arch and later Chakra Linux many years ago, I remember these things being absent when zypper (and others) had them

  - repo management
  - multilib support
  - package signing
  - key management

but all of those were added to pacman within 2 or 3 years of when I stopped daily driving Arch-based distros.

I would still characterize pacman as missing one or two sensible built-ins, although this is a matter of preference— anywhere in the Pacman Rosetta where you see pacman piped back into itself... that should just be a built-in, imo.

> I’m also not sure where dnf is more flexible, although I probably never explored it fully. What do you find about pacman to be inflexible?

Sure, I can give some examples. This also relates to some of the brittleness. Pacman's dependency resolver doesn't consider installed packages in a first-class way— it only examines version constraints for new stuff or updates it's grabbing from the repo. This is part of why 'partial upgrades' aren't supported and all of why your AUR-installed packages are liable to break after `pacman -Syu`, requiring sane AUR wrappers to rebuild your AUR packages after each system upgrade.

Package managers like dnf and zypper make it possible to group specific repos together and mark them as interchangeable when evaluating updates. They also have facilities for tracking which repos (or classes of equivalent repos) you've gotten packages from and make it easy to tell when an upgrade or installation might require you to change the 'supplier' of a given package. It's easy to prioritize and layer multiple repos together in a sane way without breaking your system with them, but with pacman all you have to will with is a total order for whole repositories, and the Ignore(Pkg|Group) configurations.

Honestly I should probably try running Arch again for a while to help update what I think of pacman.

[DivineBicycle]

> Additionally, by the time I started messing with RPM packaging, I had already packaged for Gentoo, Arch, and Ubuntu, so I think I had already developed some intuitions for how to explore packaging systems and their documentation.

Ah, that might have helped I suppose. I haven’t done any sort of packaging in the past so that might have not helped.

> but all of those were added to pacman within 2 or 3 years of when I stopped daily driving Arch-based distros.

Ah, that would explain why I hadn’t experienced that myself, having only switched to Arch about a year ago now.

> it only examines version constraints for new stuff or updates it's grabbing from the repo. This is part of why 'partial upgrades' aren't supported and all of why your AUR-installed packages are liable to break after `pacman -Syu`, requiring sane AUR wrappers to rebuild your AUR packages after each system upgrade.

Isn’t this, while being slightly inflexible, reasonably logical with Arch being rolling release? I was under the impression that you weren’t supposed to upgrade anything individually, as that upgrade might cause the need for a newer version of some dependency, which could break other packages.

> make it easy to tell when an upgrade or installation might require you to change the 'supplier' of a given package

This has worked fine for me with packages installed from the AUR (through yay), although I can’t think of any examples, but I think it’s only happened once or twice.

> Honestly I should probably try running Arch again for a while to help update what I think of pacman.

I would recommend that you do, as Arch is the best distribution ever! :P

Thanks for sharing that information, as I’ve never heard anyone talking about pacman at that time, so I’d assumed it was always like it is now. It was very enlightening.