Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Red Hat (the company) and RPM (the format) predate Debian, although only by a few months. Also RPM is a much better format than deb, and that's speaking as someone who regularly makes packages using both.

I would also say that dnf and zypper are better package managers than apt, in as much as they are faster and easier to automate. Compare the code here:

https://github.com/libguestfs/libguestfs/blob/1.29.43/custom...



For those of us uninformed, why is RPM a better format than deb?


Primarily the all-in-one spec file is a lot easier to read and write than the scattered files of deb. Also the build system is considerably simpler and more coherent -- you don't have the mess of dh vs cdbs vs flavour of the month. RPM has a nice language and macro system. It's not that deb is bad, just that when I have to package for both, I find the RPM one simpler and easier.

Here is a relative simple package, done for both RPM and .deb. The RPM spec is 141 lines (excluding the changelog):

http://pkgs.fedoraproject.org/cgit/virt-top.git/tree/virt-to...

The .deb is actually shorter in this case, but split over several files, and uses cdbs which I find infuriating with its lack of documentation and multiple hidden implicit rules. If you have a Debian machine around, try reading the /usr/share/cdbs/1/ files some time. Remember also that for most Debian packages, the files come in a tarball or even a patch, which makes them hard to manipulate without obscure deb-* commands.

https://anonscm.debian.org/cgit/pkg-ocaml-maint/packages/vir...


What? how is this better? what all of this is is apt making users say yes to everything such as config changes. I'm totally fine with that. Sure it's an extra line or 2 when automating, but I don't see it as bad.


I don't know about you, but I'd rather use the tool that I don't have to hack the training wheels off of first when I'm trying to update 100,000 machines to mitigate a critical security issue.


1. Security updates don't add debconf prompts 2. Supporting large numbers of systems is exactly when a persistent local configure database becomes useful for avoiding unanticipated regressions




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: