[Fedora-packaging] Re: RPM weirdness [moved from fedora-list]

[Philip Prindeville]

Axel Thimm wrote:

>On Sun, Dec 10, 2006 at 03:50:06PM -0700, Philip Prindeville wrote:
>  
>
>>Philip Prindeville wrote:
>>
>>    
>>
>>>>I'm a flailing at cluefulness here.  Maybe someone can set me straight.
>>>>
>>>>I run "yum" nightly (as as service), but I see a lot of "*.rpmnew" files
>>>>being left around.
>>>>
>>>>What's most bizarre is that the original RPM files haven't been changed,
>>>>and often the two files have the same size, contents (and hence MD5
>>>>signature), permissions, ownership, etc.  Even the same file modification
>>>>date in most cases.
>>>>
>>>>So why do they get left behind?
>>>>
>>>># cd /etc/security
>>>># ls -ltr chroot*
>>>>-rw-r--r-- 1 root root 82 Aug  1 05:18 chroot.conf.rpmnew
>>>>-rw-r--r-- 1 root root 82 Aug  1 05:18 chroot.conf
>>>># diff -c chroot.conf.rpmnew chroot.conf
>>>># mv chroot.conf.rpmnew chroot.conf
>>>>#
>>>>
>>>>
>>>>Thanks,
>>>>
>>>>-Philip
>>>>        
>>>>
>>
>>
>>Bingo:
>>
>># ls -l /etc/security/chroot.conf*
>>-rw-r--r-- 1 root root 82 Aug  1 05:18 /etc/security/chroot.conf
>>-rw-r--r-- 1 root root 82 Aug  1 05:18 /etc/security/chroot.conf.rpmnew
>># perl -e 'print join(", ", stat("/etc/security/chroot.conf")), "\n"'
>>64768, 721510, 33188, 1, 0, 0, 0, 82, 1154431139, 1154431139, 1156023232, 4096, 8
>># perl -e 'print join(", ", stat("/etc/security/chroot.conf.rpmnew")), "\n"'
>>64768, 719917, 33188, 1, 0, 0, 0, 82, 1154431128, 1154431128, 1156023323, 4096, 8
>># perl -e 'print scalar localtime((stat("/etc/security/chroot.conf.rpmnew"))[9]), "\n"'
>>Tue Aug  1 05:18:48 2006
>># perl -e 'print scalar localtime((stat("/etc/security/chroot.conf"))[9]), "\n"'
>>Tue Aug  1 05:18:59 2006
>>#
>>
>>And there you have it.
>>
>>Why are the packages being generated with a few seconds jitter?
>>
>>This seems to be generating a lot of .rpmnew files gratuitously.
>>    
>>
>
>Looks a bit like multilib. E.g. config files existing in two packages,
>an i386 and an x86_64 one.
>
>If it were a single package and rpm upgrades it it registers that the
>config files have not changed, so the new one can be put in place.
>
>But if you do that for two packages in a row that contain exactly the
>same config files, then the first update will have changed the config
>files properly, but the second update will think the user changed the
>config files manually and will go the rpmnew route.
>
>So the question is: Is that a x86_64 system? If yes, then we need to
>think about config files in multilib. If not, then forget about the
>above consiracy theory. ;)
>  
>

Well, in two cases that I looked at, that turned out to be true.

Not sure if there were any exceptions.  Maybe samba-common.
I'll pay attention in the future when I see it happen next...

I'm still not clear, though:  if the file being installed is part of the
sources that's being built (i.e. it's not a generated file), and the
makefile that does the install invoked "cp --preserve=timestamps"
then both the .i386 and the .x86_64 copies should have an identical
timestamp.  Right?

-Philip


-Philip