[Fedora-packaging] config files in multilibed packages (was: RPM weirdness)

[Axel Thimm]

On Sun, Dec 10, 2006 at 10:17:41PM -0600, Rex Dieter wrote:
>  Philip Prindeville wrote:
>  
>  > 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?
>  
>  Consider the case where the installed file(s) are build-time generated.
>   These are *very* unlikely to have identical timestamps (having been
>  built separately on different archs/buildhosts). 
I think that's it. Going back to Philip's example on
/etc/security/chroot.conf (he didn't mention which distro, but the one
matching his timestamps is FC5): On FC5/x86_64 one gets:

# rpm -qf /etc/security/chroot.conf
pam-0.99.5.0-5.fc5
pam-0.99.5.0-5.fc5
# TZ=C ls -ld --full-time /etc/security/chroot.conf
-rw-r--r-- 1 root root 82 2006-08-01 11:18:48.000000000 +0000 /etc/security/chroot.conf
# rpm -V pam.i386| grep chroot
# rpm -V pam.x86_64| grep chroot
.......T  c /etc/security/chroot.conf

So the i386 package thinks all is fine, while the x86_64 package
thinks the config file has been altered manually. So the x86_64
package will not touch that file on upgrading and generate an rpmnew
file.

BTW I wonder why multilib allowed i386 to win over x86_64 on my
system. Looks like a different issue, but perhaps the above only
triggers in such cases.

There are several points to learn here:

a) always use install -p or similar, e.g. preserve the time stamps
   while packaging. This is a general rule of reason and we see here
   that it can trigger other bugs

b) avoid packaging config files in multilibed packages. E.g. pam
   should split off a libpam subpackage and we should only multilib
   that.

c) investigate what happens on multilib upgrades and config
   files. Something is obvioulsy broken there.
-- 
Axel.Thimm at ATrpms.net