Why the RPM source and binary package format is superior to Debian .debs
In an earlier entry I mentioned that I felt that RPM was a better package format in practice than Debian .debs. Today it's time to take a stab at justify this. But to start with, let's talk about what this entry is not about.
In the old days Debian was superior in practice because the whole apt
software suite and ecology had no real equivalent in RPM land. Those
days are long gone. These days
yum is as much as part of the RPM
ecology as apt is for the Debian package one, and in fact the
command has been demoted to the same general footnote status that
is in Debian. Having used both I feel that yum and apt are sufficiently
comparable that I'm not going to quibble back and forth. So this entry
is purely about the package format itself, not the surrounding tools.
There are two sides to this, source packages and binary packages. In the source package world, RPM is in the lead because of the way that it systematically organize changes to the source and does builds outside of the package's source area. I wrote about this at length here and here on the hassles of working with Debian sources, here on the different tradeoffs of Debian and RPM source packages, and here on why the Debian tradeoff is the wrong one.
For binary packages I'm going to set aside Debian's misstep with x86 multi-arch support, partly because I understand it's increasingly being fixed. In practice there are two important differences between the package formats: RPMs can and generally do depend on files while .debs depend on packages and Debian packages can ask you questions at install time while RPMs never do. The dependency issue is the lesser one. Depending on packages is brittle in the face of other people reorganizing their packages and also requires a somewhat indirect process for determining a package's dependencies when the package is built. Depending on files means that RPMs are agnostic about just what provides those files and the RPM build process can easily determine most dependencies by direct examination of packaged programs and so on.
In the abstract asking questions at install time sounds great or at least harmless. In practice it's a disaster that enables a catalog of bad practices, ranging from people papering over internal divisions through ambushing sysadmins with landmines to drastically complicating attempts to do automated and semi-automated installations and package updates. By contrast RPMs have a very hard rule, enforced by the system, that a package cannot interact with the user at install time at all. Packagers are forced to make decisions and insure that the package setup is sane, while sysadmins can script and otherwise automate RPM installs without worry.
Theoretically you can turn off all install time questions on Debian. In practice this can't be trusted because it's not the default state of affairs. Oh sure, it's probably considered a bug if a Debian package screws things up on a no-questions install, but do you want to be the first person to find that bug? If you are a sane sysadmin, the answer is 'no' (not unless you have no choice). In practice what is fully supported is what is routine and in the Debian world that's asking you questions during package installs.
(It's possible that graphical package management is changing this, but I'm not holding my breath.)
A slow realization: many of my dotfiles don't need to be dotfiles
Like many Unix people, I have a slowly accumulating drift of dotfiles
(and dot-directories) cluttering up my
$HOME. It has recently struck
me that a certain amount of these dotfiles are in fact a self-inflicted
injury, by which I mean that they don't actually have to be dotfiles in
$HOME and I could move them elsewhere if I wanted to. There are two
variants of this injury.
The first variety is where I have simply made a file a dotfile in
$HOME out of reflexive habit. There is no system-supplied program that
expects to find it there; I have simply needed a file for some purpose
and made it a dotfile because it seemed to make sense. For example,
I have a set of X resource files that I made into dotfiles basically
just because. Since it's my X startup script that loads them into the X
server, they could perfectly well live in, say,
some set of sensible (and visible) names.
(Often there is some sort of vague link to something that was a necessary dotfile back in history.)
The second variety is where a program defaults to using a dotfile but this can be changed with a command line option and I already run the program in some automated way (through a cover script or the like). Here I can perfectly well change my automation to relocate the dotfile to some better place. There are probably a number of programs I'm running like this.
(Similar to this is things that can be moved with an environment
Certainly going forward I think my rule is going to be that I won't
create any new dotfiles unless I have absolutely no choice. Relocating
existing ones, well, I have a lot of inertia and my existing setup
works, it's just got a massive clutter in
$HOME that I can't see
unless I do an '
(Why dotfiles are a bad idea is probably not necessarily obvious, but that's another entry.)
PS: what brought this realization on was building out a version of my environment for Cinnamon on my laptop. When I was copying dotfiles over to the laptop and working on them I started asking myself why they actually were dotfiles instead of being organized somewhere sensible where I could see them.