There's a very complex interaction between the various files which define a package. It's extremely hard to find out what debhelper and its associated commands are actually doing and to debug them, particularly if you're trying to split a package into multiple parts. I gave up several times trying to make my package before finally succeeding with a simplified version. I'm not sure I will understand how it works when I go back to it.
On top of that the sheer volume of rules and regulations, different packaging helpers and out of date suggestions just added to the problem.
Deb has far too much magic. Rpm is much clearer. I can define a simple configuration file which takes the source, patches it, builds it, and describes the packaged files. I've never had a problem understanding an rpm source package.
As a sysadmin, of one box or 100k boxen, I'd have a hell of a lot less apprehension about installing a DEB than an RPM. Thanks largely to Debian Policy, which governs how packaages will behave.
The fact that Debian has an order of magnitude more in-repo, in-distro packages also counts for something.
As well as the fact that I can start with a minimal installation and add to it only what the box actually needs, a process Red Hat and RPM have never adequately supported.
Source: Have run both, personally and professionally, for nearing a quarter century.
Nowadays the competitive edge of APT could have diminished, but I never looked else where because I have been quite happy with APT.
Once I needed a package from an external repository, apt has almost always fallen down into a pit of duplicate and incompatible dependencies. Maybe it’s better now, but I was burned long ago and never looked back.
Portage is cute but it's tied to Gentoo and few people want to compile their own packages.
Apt was one of the earliest package managers for Linux, for a popular distribution. That was enough to give it a head start regarding packages available. And that's all you need, unless the other solutions are obviously superior from the user perspective, which they're not.
Strongly agree. Gentoo's Portage is the best experience I've had with a package manager on Linux.
My package management observations, as someone who's been using them for... a while, now.
Best experiences: Portage on Gentoo (lots of options; many packages; fast; reliable unless I broke it doing something stupid; maintaining a high level of control over the system at a low level is the only way I've ever managed to make Linux behave itself), Homebrew on MacOS (great package selection; casks are wonderful; outstanding CLI; keeping user packages away from the core system has really grown on me)
Middling: apt on Ubuntu and Debian (OK but increasingly feels dirty after getting used to Homebrew and keeping my user packages separate from the system; breaks "on its own" more often than Portage did, though still rarely; package selection just OK)
Bad: Yum/RPM on Red Hat, Fedora, and long ago, RPM on Mandrake (sloooooooowwwwwwwww and RPMs seemed to break constantly back when I used them), Macports on MacOS (slow; broke so bad the easiest thing to do was to delete the whole dir and start over about once a quarter; limited package selection)
Incidentally, Gentoo's OpenRC is the only Linux init system I've ever used that I liked and felt like I actually understood well enough to use it without apprehension or constantly needing to check documentation.
I like the idea of Nix and tried NixOS once but after an hour or so of following a guide and troubleshooting couldn't get X running so gave it up as "for those with more free time than me—try again in a few years".
I try about 1-2 other distros every year (in VMs or a spare laptop), and I always stay with Gentoo. I won't go so far as to say that it's objectively better, but after 10 years or so just nothing else compares for me.
Using RH easily led you into an "rpm hell" of packages from various third-party repos that conflicted: https://en.wikipedia.org/wiki/Dependency_hell#Platform-speci...
Now they're both comparable. Yum/dnf are ok, the rpm repos are big. And apt actually has "apt", the tool, that consolidates those separate tools you mention. Before it had aptitude (since at least 2006 or so, I'd say) but it wasn't used much, but now apt is installed by default and you can use it. No more "apt-get", "apt-cache", etc.
So today, nothing makes one of them substantially better, IMO.
As a consequence, Debian packaging policy is (in my experience) a lot more aggressive about using detailed dependency-resolution metadata to establish constraints and define compatibility, which makes for a more annoying developer experience but a nicer end-user experience.
I started using it before 2005, before backports was a thing, and it was a lifesaver for my desktops, as I usually wanted to use newer versions from testing or unstable.
[1] https://www.debian.org/doc/manuals/debian-reference/ch02.en....
For apt as a format probably not so much anymore. For the Debian apt repositories it's the several thousand capable and driven maintainers.
If anything, Red Hat should have adopted apt.
In terms of sheer number of dumb competing initiatives, Ubuntu > Red Hat > Debian.