For not caring a lot about open source, they have many MANY more open source developers than Canonical does, or likely ever will have. Also, I suspect quite a few Redhat employees will take strong offense to your comments on them not caring about Free Software. Funny, Redhat never had issues such as this that Canonical did about licensing terms not being GPL friendly, which they have since fixed: https://www.fsf.org/news/canonical-updated-licensing-terms

I'll totally agree with you on Debian vs Ubuntu, but on Redhat vs Debian... We can agree to disagree. Here is a paste of an email I wrote up to some coworkers on the subject:

======================================================

RPM starts off with the concept of pristine sources. It is vehemently rejected that a maintainer of a rpm package use a non-upstream tarball or change _anything_ without a patch that is in version control. This is not the case with dpkgs

RPM

===

•	Stores ownership, permissions, and checksums in the rpmdb. This allows for tools like [1] which are entirely impossible to re-create a dpkg equivalent. There is no equivalent of the insanely handy “rpm –V” in dpkg.

•	The checksum is part of building a rpm package. The “debsums” functionality is not actually required for all packages. In fact, until Ubuntu got their act together and started fixing a LOT of stuff, many debian packages, didn’t have their checksums in the db.

•	Changes are atomic. They use the bdb transactions and rollback. Either something was installed (via CPIO) or it was not. Debian package manager uses flat text-files! Those flat text files live under /var/lib/dpkg [Figure 1 below]. There are about 3-4 of these files per package, and they often times corrupt, resulting in impossible to uninstall packages. This simply doesn’t exist with rpms.

•	The Debian package format lacked multiarch support until Jan 31, 2012[2]. Up until this version, installing a 32 bit deb on a 64 bit operating system involved creating a full system 32 bit chroot (I shit you not!), with hundreds of megabytes of silliness. Rpm has had multiarch basically since the majority of Fedora compiled with 64 bit compilers (around early 2005).

Package creation
o	RPM packages have 1 command, rpmbuild, for creating a binary or source rpm. You have a single file ${package_name}.spec, and the source tarball. That is all you need for a rpm. If you want to build the package in a “clean room” chroot, you can use mock, which runs as non-root

o	For creating a deb package, you have dpkg-source, dpkg-buildpackage, dch, etc. For debs: Do you use debhelper or do you use cdbs? What version of debhelper, what version of cdbs? Which is deprecated and which is the “preferred” way? You have to edit the control file, the rules file, the package list file, the changelog has to have the perfect format or all hell breaks loose, etc. If you don’t put the exact same info in the control file and the package.dsc, woe be unto you! Once you’ve got that all done, you have to create a “debian source package”. Don’t get me started on that stupidity, seriously, it is worse than this entire thread.

•	Multiple utilities. There is rpm. Then there is dpkg, dselect, dpkg-query, dpkg-reconfigure, dpkg-deb. dpkg-<TAB><TAB> results in 35 results on my test Ubuntu box and almost 30 for deb<TAB><TAB> mostly debconf stuff and almost 70 for dh_* for debhelper grossness. There are a couple of helpers like rpmquery (shortcut for rpm -q), or rpmverify (which is a shortcut for rpm –V), but they are symlinks back to rpm for convenience. One utility, one man page, less ambiguity.

•	Templating. A rpm spec file is simply a shell script with some substitutions. Debian packages are all built using some extremely customized autotools and autotools like macros, each with conflicting versions and competing implementations (try to figure out if you’re supposed to use cdbs[3] or debhelper[4]). Both debhelper and cdbs exist because it is so impossibly hard to build debian packages by hand without some serious pain. There are macros for rpm spec files, but not even remotely the same complexity or necessity.

•	With dpkg, it is possible to get into states which are impossible to resolve with the cli utilities (even dpkg –-configure –a). This always results in having to manually edit the pre/post hacky script under /var/lib/dpkg and is serious voodoo black magic that only experts should ever do. The problem is that it isn’t uncommon. If the pre/post scripts do ever fail bad enough to where you can’t fully remove a package, you can do rpm –e –-noscripts. Debian packages have this “rc” state where they are partially installed / uninstalled, but not fully either. Then you have to purge them using dpkg –-purge, and that is assuming that you’ve successfully hacked up the scripts that read the plain text files under /var/lib/dpkg. The entire design is unbelievably fragile. They make it a bit less fragile by writing an ENORMOUS debian packaging policy[5] to try to get people to work around silly limitations in the software via policy. This is against one of the fundamental design choices of rpm, which is that package installs should be atomic. It is either installed, or not installed. There is no “I’m half installed” status for rpm packages.

Hopefully this is a reasonable technical defense of rpm’s superiority over dpkg. What blows my mind is that Ian Murdoch made Debian after Redhat Linux existed but before YellowDog wrote yum. He had time to study the internals of RPM and design something superior. Instead, he NIH and invented something that on most levels to this day is still technically inferior. The yum vs apt debian isn’t near as lopsided where old apt > old yum, but new yum is unbelievably > than new apt. That is for another day, and only if you’re interested.

[1] http://www.digitalprognosis.com/opensource/scripts/restorepe...

[2] https://lwn.net/Articles/485349/

[3] http://build-common.alioth.debian.org/cdbs-doc.html#id250485...

[4] https://joeyh.name/code/debhelper/

[5] https://www.debian.org/doc/debian-policy/