For some of those I agree with you, but I think several of those are easy claims to defend.

> strong focus on user experience [...] it will not let you down [...] the user can rely on predictability. [...] offer their users uncompromising release quality

Fair claims in light of OpenSUSE Tumbleweed's extensive testing. It is remarkably stable for a rolling release distro, and furthermore, Tumbleweed comes pre-configured with BTRFS and snapper. That means that if anything does go wrong, rolling it back is trivial. Compared to Debian Sid, I now do much less fiddling and fixing. This is the main reason I use Tumbleweed instead of Sid; I got sick of worrying about breakage every time I updated Sid.

> powerful package management system

Zypper has a SAT solver for dependency resolution, in my experience it works a lot better than apt/yum, which I always found prone to jamming themselves particularly during dist updates. Maybe the situation has changed recently, I haven't kept up with apt/etc developments, but assuming that situation hasn't changed much in the past 10 years I think it is fair to say Zypper is more powerful than most of the competition.

> a high-end enterprise Linux distribution that you can rely on [...] offer their users uncompromising release quality

True, for SUSE Enterprise Linux.

> strong focus on user experience and flexibility [...] with-user-in-mind approach

True: YaST. In this regard SUSE is far ahead of Debian/Fedora/Ubuntu/etc. I believe whatever Mandrake derivatives might still exist have something similar.

FWIW, Fedora these days use dnf, which uses libsolv under the hood.

https://github.com/rpm-software-management/dnf https://docs.fedoraproject.org/en-US/quick-docs/dnf/

dnf has copied zypper's other innovations as well, like vendor change.

It's also fully usable on openSUSE, as a replacement for zypper, if you so desire. :)

dnf and zypper are the best of the 'old school' package managers, in my experience (and to my taste). If want traditional package management, you can't go wrong with either.

what are you calling the new school?

There isn't a single one, but off the top of my head, the following package managers have been used to meet the same need (building Linux distros) but use distinct and relatively new paradigms or techniques:

  - Guix, Nix
  - Distri
  - Luet

(I'm personally partial to the 'functional' school, which means Nix and Guix. :)

One might also count package managers that are designed for building large, multi-language distributions of software but have never been used to build a whole distro. In that case, you could also include

  - Spack
  - Denxi

and finally you might also include tools that build on top of the traditional stuff, like `rpm-ostree`. This is what you're dealing with on Fedora Silverblue, SteamOS, openSUSE MicroOS, etc.

Also distinct from these but not particularly new are source-based package management systems, like

  - source-based Linux distro package managers incl.
    - emerge
    - paludis
    - sorcery
  - various ports systems, incl.
    - pkgsrc
    - Ravenports
    - FreeBSD Ports
    - Dragonfly BSD's DPorts
    - MacPorts
    - Homebrew

but those aren't really in the mainstream of system-wide package management, at least from my Linux-centric perspective, so I don't usually mean them when I refer to 'traditional' or 'conventional' package managers without any other qualifiers.

Anyway yeah, plain old openSUSE and Fedora are great choices if you don't want a declarative system or immutable Linux, and that is in part because zypper and dnf are best-in-class for their paradigm.

wow, thank you! but are there linux distros that use any of these "from scratch" or as their native system for updating the kernel and reconfiguring grub, etc? or, to ask a different way, could these systems do that?

NixOS and GuixSD are distros built entirely around Nix and Guix, respectively.

In a word: yes! That I know of, Guix, Nix, and Luet are the only ones with whole, bootable Linux distros built on top of them so that the 'package manager' also does configuration management in some form. (IIRC, Luet is more traditional here, it manages config files only state fully and partially, using hooks and triggers.) Those distros are very worth checking out! The operating systems built on them are GuixSD, NixOS, and MoccacinoOS, respectively.

Distri is a system-wide package manager, but its distro is a PoC. It has a small package collection and no users, last I checked. But it has some cool innovations and it's very fast, so if you want to play with building a distro on a next-gen package manager, it seems great!

I think Denxi could be used to build an OS in a similar way as Nix, but I'm not aware of any such effort currently. The same is true of Spack.

Haiku and RedoxOS have some fancy Nix-like package management features as well, in terms of rollbacks and multiple versions of transitive dependencies playing nice together on the same system, and maybe in some other ways, too.

Nix probably?

Yep, but I'd also count some package managers which have learned from Nix but chosen a slightly different path by relaxing the requirement of 'purity', or leaning harder on containerization features.

Besides the ones I mentioned in my reply which is a sibling to yours, I think the package managers for Haiku and RedoxOS fall into this category (but I can't be sure! I've never used them, so my memory of how where work is likely to have gaps).

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.

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

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

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

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

It’s been about 2 WEEKS since I had apt shoot itself in the foot and basically deadlock in a state where I can’t perform a repair, upgrade, downgrade or reinstall. Time to forcefeed dpkg everything apt and libc

It cured my ED and my skin is clearing up so speak for yourself