The source of spurious
I wrote before about how updating RPMs would
.rpmnew files behind that were, in fact,
identical to the normal version of the file. I believe that I now
understand what causes this and what's going on: I think it's another
manifestation of the RPM multi-architecture file ownership problem.
.rpmnew files are created when you update a package where you've
changed one of its configuration files from the default version and
the package also includes a new version of the configuration file. RPM
checks for changes by comparing the MD5 checksum of the installed file
against the MD5 checksum in the database for the old package; if they
differ, you've edited the configuration file.
The problem comes up when you upgrade a package that you have for both architectures with a (shared) configuration file. The configuration file is 'owned' by both packages, and RPM applies updates one by one and immediately puts new files (including new versions of shared files) into place. So I think that what happens goes like this (as an example):
- RPM updates libfoo.x86 from 1.1 to 1.2. The (shared) configuration file
/etc/foo.confis the stock 1.1 version, so it gets replaced with the version from libfoo-1.2.x86.
- RPM updates libfoo.x86_64 from 1.1 to 1.2. Since
/etc/foo.confis no longer the stock 1.1 version, RPM creates the libfoo-1.2.x86_64 foo.conf as foo.conf.rpmnew.
Thus, to see the problem I believe that you need to be on a multi-arch machine, update a package that you have for both architectures, and have that update change a configuration file. This seems to be fairly uncommon, at least for the packages that I have installed on my machines.
(I think that this is an RPM bug, though, not just a natural consequence of how things work in a multiarch world. RPM could be smart enough to realize what is actually going on and really should be, since the current behavior is not really correct.)