Bug 62366

Created attachment 51464 [details]
Test spec file: build two copies, install first, upgrade to second, do rpm -V.

Try
	rpm -V --nomtime <pkg>
I see no purpose in attempting to change the file mtimes
to agree with database entries. In fact, that's the wrong
thing to do, as it will interact badly with, say, find -newer
used to backup systems, and suffers from all the vagaries
of trying to keep an accurate system time.

OK, now I can really point my finger on what's wrong about this whole thing.
Imagine, we have 3 versions of the package: 1-1 and 1-2 have the same
%config(noreplace) file with different timestamps and 2-1 has a modified version
of it. Now
1) Install 1-1, everyting is OK
2) Upgrade to 1-2, now the fs has the 1-1 timestamp and db has 1-2 timestamp.
Not great, but tolerable.
3) Upgrade to 2-1. Now since the fs does not comptely match the db, the .rpmnew
will be created!!!!!

End result: I get a .rpmnew file for a config *I never touched*. This is not
just a theoretical problem - I arrived at this while trying to figure out why
7.2 -> Skipjack upgrade created that many .rpmnew files for configs I have never
touched. And I had to spend 20 minutes looking at all of them, making sure that
indeed I never tpuched the config and then doing "mv xxx.rpmnew xxx" for all of
them!

Yes, you might argue that (2) alone may be a good idea and that (3) alone may be
a good idea as well, but *together* they form a difinite bug and one of them has
to go...

P.S. What's interesting is that only noreplace configs have this problem,
without it (3) would work correctly and not create any .rpmsave. This leads me
to thinking that (3) is the bug, not (2).

P.S. rpm from the 7.2 updates suffers from this problem as well.

*** Bug 60299 has been marked as a duplicate of this bug. ***

Yet another serious issue caused by this is with up2date thinking that config
was modified:

1) A package is installed.
2) A package is upgraded with a version that contains the same config file with
a different timestamp. rpm fails to update the timestamp.
3) A package with a different config file is added to RHN. up2date decides to
add it to a skip list because it thinks config file was modified (but it was
not, only timestamp does not match the db).

Just saw this with XFree86-??? -> XFree86-4.2.0-6.52 -> XFree86-4.2.0-6.62

Again, it's not clear what's a bug - 2 or 3 (or both) and which can be
considered a good behavior, but 2+3 is definitely a bug. 

-------

I am starting to think that timestamp not matching the db should be considered a
bug, no matter what the advantages are - too many packages are likely to
consider this to mean that the config was modified which causes too many problems.

You're chasing a red herring, the %config handling does
noty look at mtime at all, and that problem is fixed in
rpm-4.0.4-7x.15.

Again, the file system has the master copy of the file
modify time, because that's the Right Thing To Do. What's
in the database is a time stamp of the modify time when
the package was built. These are different uses.

Use --nomtime if you don't want to be bothered.

Thanks, this indeed works correctly with 4.0.4-7x.16. 

P.S. The WONTFIX resolution does not seem that accuate since the problem with
rpm creating .rpmnew for configs that were never modified did exist and is now
appears to be fixed. But this, of course, is not that important.