.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
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
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
.rpmnewfiles. 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
.rpmnewfile 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
files for various reasons).