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
Attachment:
pgpP7RClma9NM.pgp
Description: PGP signature
-- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
