== The source of spurious _.rpmnew_ files

I [[wrote before RpmnewFixup]] about how updating RPMs would
occasionally leave _.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
RPMMultiarchFileProblem]].

The _.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.conf_ is 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.conf_
  is 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.)