The core difference between Debian source packages and RPMs
September 9, 2012
At least from my perspective, the two big source package formats in the Linux world are Debian's and (source) RPMs. I've worked with both (although far more with RPMs than with debs) and recently I've formed an opinion on what the core difference between them is and what each is better (or best) at.
The Debian source format is optimized for the case where the 'upstream' developer is also effectively the Debian packager (in what Debian calls a 'native' package). The Debian control files live in the general distribution tarball and you can build Debian packages right from the development tree with no fuss and bother. You don't need to have any extra bureaucracy or keep things outside the source tree.
The RPM source format is optimized for packaging (and changing) other people's packages. Everything lives outside the source tree (indeed in a completely separate area) and from the start all modifications were supposed to be made as a sequence of patches. In theory RPM has support for 'native' packages, packages with a spec file integrated into their source tarball, but I don't think many people really use this and it's certainly not the natural way to work with RPM packages.
Even though RPM has some 'native' support, it has no way to build a package from an unpacked source tree the way that Debian does. By contrast, building from an unpacked tree is the fundamental operation in Debian packaging. If you're developing your program and want to repeatedly build the package the Debian approach is much more convenient. The flipside is true (in my opinion) if you're packaging and possibly modifying an upstream package; there the RPM approach is cleaner and easier to work with, as I've sort of grumbled about before.
This doesn't quite make arguments about which source format is better into arguments about editors, but in my opinion it does move the question one step removed. The right question is not which is better but which situation is more common.
(In my biased opinion I believe that the answer is 'packaging other people's programs' and in fact it's proven to be a mistake to have the upstream developer try to also package the program, but the latter is a topic for another entry.)
* * *
Atom feeds are available; see the bottom of most pages.