Bug 132392 - duplicated /etc/default/nss with different times on multiarch glibc (i686 and x86_64)
duplicated /etc/default/nss with different times on multiarch glibc (i686 and...
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
x86_64 Linux
medium Severity low
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
Blocks: FC3Target FC4Target
  Show dependency treegraph
Reported: 2004-09-12 03:46 EDT by Arenas Belon, Carlo Marcelo
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.3.3-79
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-01 07:38:51 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Arenas Belon, Carlo Marcelo 2004-09-12 03:46:40 EDT
Description of problem:
both: glibc-2.3.3-49.i686 and glibc-2.3.3-49.x86_64 include
/etc/default/nss on their %files list.

the problem gets even worst by the fact that the file /etc/default/nss
gets copied at %install time and later rolled as part of the rpm and
therefore has different access/modified times on each package leading
rpm to believe they are totally different files and forcing it to make
an .rpmnew copy on install.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. up2date glibc
2. ls /etc/default
Actual results:
nss nss.rpmnew

Expected results:

Additional info:
observed also on other recent releases of glibc

using `install -p -m 644 nis/nss $RPM_BUILD_ROOT/default/nss` instead
would at least keep the same time on the package and probably help rpm
identify this file as a duplicate and avoid the backup (probably not
working like that yet)
Comment 1 Jakub Jelinek 2004-09-30 03:50:22 EDT
The file is
%verify(not md5 size mtime) %config(noreplace) /etc/default/nss
I wonder why the same problem doesn't exist for nsswitch.conf, it also
has different timestamp between the two rpms and is also
%verify(not md5 size mtime) %config(noreplace) /etc/nsswitch.conf
Comment 2 Arenas Belon, Carlo Marcelo 2004-10-03 06:20:22 EDT
still not working for glibc-2.3.3-63 which is using install -p on the
SPEC for those files.

the list of files provided by both (i686 and x86_64) packages is :


where all the configuration files (except for /etc/rpc) are tagged as
%verify(not md5 size mtime) %config(noreplace)

additionally, the files on [/usr]/sbin and which are different on each
architecture dependent file are getting overwritten but the last
installed package (on my case it was x86_64) as shown below :

[root@localhost ~]# rpm -V glibc.i686
S.5....T    /sbin/ldconfig
S.5....T    /sbin/sln
S.5....T    /usr/sbin/glibc_post_upgrade
S.5....T    /usr/sbin/iconvconfig

it is interesting also to note that the file which actually got
installed for /etc/rpc matches the one for glibc.i686 and conflicts
with the one on glibc.x86_64 though as shown below :

[root@localhost default]# rpm -V glibc.x86_64
.......T  c /etc/rpc

Comment 3 Jakub Jelinek 2004-10-19 05:51:12 EDT
Jeff, any ideas?
I get
   5:glibc                  warning: /etc/default/nss created as /etc/default/nss.rpmnew
rpm -qplv glibc-2.3.3-70.i686.rpm glibc-2.3.3-70.x86_64.rpm | grep /etc/default
drwxr-xr-x    2 root    root                0 Oct 19 02:38 /etc/default
-rw-r--r--    1 root    root              962 Apr  2  2004 /etc/default/nss
drwxr-xr-x    2 root    root                0 Oct 19 02:08 /etc/default
-rw-r--r--    1 root    root              962 Apr  2  2004 /etc/default/nss
md5sum /etc/default/nss*
eda53e55824cb30fbd378349352f559d  /etc/default/nss
eda53e55824cb30fbd378349352f559d  /etc/default/nss.rpmnew

glibc.spec does:
install -p -m 644 nis/nss $RPM_BUILD_ROOT/etc/default/nss
%verify(not md5 size mtime) %config(noreplace) /etc/default/nss
Comment 4 Jakub Jelinek 2005-03-01 07:38:51 EST
/etc/default/nss is now in glibc-common since 2.3.3-79, so this should be fixed
by now.

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