Wandering Thoughts archives

Why .rpmnew files are evidence of packaging failures

The other day I tweeted:

Thesis: every .rpmsave file on a #Fedora system represents a packaging failure. The package should have provided a better override method.

(I made a mistake in this tweet; I actually meant .rpmnew files. Sadly I only noticed this mistake now.)

I should give at least one person a full explanation what I mean by this (and besides, I alluded to it last entry). In my traditional way, I'll start with a question: what creates .rpmnew files? I can think of at least three different causes:

• an upgrade of a multi-arch package that creates spurious .rpmnew files. I think that this can happen in some other situations with such shared configuration files.
• a package-supplied configuration file that then gets altered by other packages as they install or upgrade. If the original package comes out with a new version of the configuration file, you get a .rpmnew file that is basically useless.

• when the local sysadmin has had to modify a configuration file in order to properly customize or use the package. In other words, the sysadmin had to override the stock package configuration and had to do it by editing the package-provided configuration file.

The first two situations are clearly system problems. The first is a failure of the package management system itself; it should be smart enough to handle this instead of creating .rpmnew files that are exactly identical to their real version. The second is either a failure of the package or the package management system (depending on your perspective). Either way the resulting .rpmnew files are an abrogation of the system's package management responsibilities; the sysadmin made no changes but now has a mess to sort out (or more likely, ignore).

But the third situation is also a packaging failure. As I covered yesterday, the modern Linux world has developed plenty of mature techniques for configuring packages without ever having to touch package-supplied configuration files. Some of them take program changes (like support for including files or scanning directories), but those program changes are worthwhile by themselves and there are brute force techniques to deal with the situation even without program support. This is especially the case for anything that is commonly altered to configure (or reconfigure) the package; the more that the package configuration gets changed in real life, the more it should be set up this way.

(There are some package configuration files that are basically black boxes under almost all situations, where almost no sysadmin will ever touch them.)

This especially matters because packagers often understand much more about the configuration changes between package versions than most sysadmins will. Letting your package create .rpmnew files and then leaving it to sysadmins to find and merge changes is pushing the work from a few people who (should) understand the package well to a lot of people who don't necessarily (and who may not even notice the .rpmnew files for various reasons).