Why RPM's .rpmnew files don't work in practice

May 19, 2010

In theory, RPM has a solution to yesterday's bad package upgrade problem by way of what are generally called .rpmnew files. When you've modified a configuration file, update the RPM it comes from, and the new version of the RPM has also changed the configuration file, RPM does not overwrite the configuration file but instead creates <config-file>.rpmnew with the new version of it.

This does not work in practice. The problem is that there are entirely too many false positives; it is entirely routine to install packages, change nothing about them, upgrade the packages, and have .rpmnew files sprayed across your system. In this situation, requiring sysadmins to carefully diff each .rpmnew file with its original version and decipher what needs to be done is a great way to cause sysadmins to never install updates, especially because doing this reconciliation often requires us to actually understand the configuration files.

(Note that there's no universal answer for what to do with the .rpmnew files; sometimes you use them and throw away the old version, and sometimes you throw them away because your system has auto-edited important things into the old version. If you're sufficiently unlucky, the new RPM has important changes and the file has been auto-edited and you get to merge them yourself while cursing everyone concerned.)

In practice, I expect that almost everyone ignores .rpmnew files; in fact, if you use the graphical interfaces to package updating I don't think you even get told about them. The immediate consequence of this is that no package update should depend on having its .rpmnew files reconciled by hand, because it's not going to happen.

(If you build such a package update anyways, congratulations, you are an asshole. And I mean that in the technical sense.)

Just to add the icing on this particular cake, I believe that you can get .rpmnew files when upgrading multi-arch packages, for reasons that are similar to how you can get multi-arch file conflicts. This situation is at least easily recognizable, because the .rpmnew file is identical to the normal config file.

(Perhaps modern versions of RPM recognize this situation by now; I am somewhat behind on Fedora releases.)

Sidebar: sysadmins and understanding configuration files

In case it is not obvious: it is extremely common for sysadmins to install packages that have 'configuration files' that we have not read up on and have no understanding of. This is not a bad thing, it is a thing to be aspired to, because it means that your package just works without needing to be customized.

For a direct example, how many of you understand the OpenSSL configuration file, openssl.cnf? I suspect very few people do, yet pretty much everyone has OpenSSL installed and so has an OpenSSL configuration file. If understanding openssl.cnf was a requirement to installing and using OpenSSL, well, I suspect you can guess how well that would work out.

(And yes, on some of my machines I have openssl.cnf.rpmnew files.)

Written on 19 May 2010.
« An illustrated example of how not to do package updates
The limitations of C's varargs support »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed May 19 01:35:11 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.