Bug 62366 - rpm fails to update the timestamp when config file is not modified and then next upgrade creates .rpmnew
rpm fails to update the timestamp when config file is not modified and then n...
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
7.3
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jeff Johnson
:
: 60299 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-03-30 06:45 EST by Aleksey Nogin
Modified: 2008-05-01 11:38 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-04-12 15:42:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Test spec file: build two copies, install first, upgrade to second, do rpm -V. (419 bytes, text/plain)
2002-03-30 06:46 EST, Aleksey Nogin
no flags Details

  None (edit)
Description Aleksey Nogin 2002-03-30 06:45:13 EST
When upgrading a package that has a %config file identical to one in the already
installed package, but with newer timestamp, rpm-4.0.4-7x.8 just keeps the
original config and *fails to update the timestamp*. This, among other things,
pollutes the "rpm -Va" output.
Comment 1 Aleksey Nogin 2002-03-30 06:46:47 EST
Created attachment 51464 [details]
Test spec file: build two copies, install first, upgrade to second, do rpm -V.
Comment 2 Jeff Johnson 2002-03-30 11:20:21 EST
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.
Comment 3 Aleksey Nogin 2002-04-02 12:56:56 EST
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).
Comment 4 Aleksey Nogin 2002-04-02 13:02:36 EST
P.S. rpm from the 7.2 updates suffers from this problem as well.
Comment 5 Jakub Jelinek 2002-04-02 13:07:01 EST
*** Bug 60299 has been marked as a duplicate of this bug. ***
Comment 6 Aleksey Nogin 2002-04-12 15:42:51 EDT
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.
Comment 7 Jeff Johnson 2002-04-12 15:49:08 EDT
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.
Comment 8 Aleksey Nogin 2002-04-12 16:35:00 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.