Debian packaging isn&#x27;t <i>too</i> awful, though I don&#x27;t like how many files are involved (I prefer a single spec file, plus patches, as found in RPM). But, apt repository management is truly terrible. The documentation is laughably bad and disjointed, and it points to several different tools and processes that may or may not work together; my Debian&#x2F;Ubuntu repo generation script is a ridiculous mishmash of stuff that kinda sorta works if I squint and don&#x27;t look at it too closely (and a lot of the repo is manually created and maintained because I couldn&#x27;t figure out any tools to automate it).<p>Contrast that with creating yum&#x2F;dnf repos: run &#x27;createrepo&#x27; on the directory of RPMs, and you&#x27;re done! Signing RPMs is much better documented, as well. There were like three or four (conflicting and mutually incompatible) processes that come up when you google signing debian packages and repositories, and I still don&#x27;t know with certainty what the &quot;right way&quot; is.<p>I don&#x27;t know why Debian never got this part of things right; apt&#x2F;deb has been around for about two decades, you&#x27;d think someone would have looked at createrepo and said, &quot;Oh, hey, we should do something like that so it&#x27;s easier for people to distribute package for Debian&#x2F;Ubuntu.&quot;<p>All that said: I&#x27;m rarely a fan of &quot;new package managers&quot;. I like having one standard package manager on my system (I don&#x27;t really care whether it is apt or yum&#x2F;dnf), and I strongly believe everyone ought to be using the system standard package manager across all of their systems even for custom software. I don&#x27;t like the proliferation of language specific package managers, in particular. npm, gems, crates, PyPI, eggs, pear, pecl, composer, etc. Shit&#x27;s gotten ridiculous. Even on my own systems, I can&#x27;t keep up with what&#x27;s installed from where. And the problem has gotten much worse over the years; I used to package all my own stuff as RPMs, and all of the CPAN or Python dependencies, as well, using automated tools for building RPMs from Perl or Python libraries (the old cpanflute2 and the dist_utils RPM target; there are better ways in both cases, now, I think, for those languages). But, now that I have a much more diverse set of systems with more languages and more dependencies, that&#x27;s become more difficult. And, it&#x27;s also become the norm for people to document only installation with oddball package managers (npm, in particular, is the way everyone documents everything these days), with no good mechanism to package for RPM or deb.<p>I dunno, I think we&#x27;re going down a risky path with all these &quot;package managers&quot; that only work for one little niche and I believe security issues will be the major negative side effect. I mean, I have great tooling to let me know when my RPMs or debs are out of date across my couple dozen servers; it&#x27;s much harder to know when packages installed via all those other systems are out of date; it becomes a manual process in some cases, and it&#x27;s also risky because dependencies are not always very reliable in those systems. I do a lot of, &quot;Will this break some other thing when I upgrade this library?&quot; Which I don&#x27;t worry about with RPM updates from CentOS (because of the compatibility assurances of that system), or from my own company repos (because we do our own testing and understand the parts we&#x27;re distributing).<p>In short: Yes, it&#x27;s hard to package and distribute for RPM or deb. But, not as hard as dealing with a half dozen different package managers, containers, and a wide variety of other things being updated via a wide variety of other mechanisms. The former is hard but quantifiable and manageable. The latter is a nightmare for security and reliability.