Description of problem:
i was looking for iwlist pkg owner - so i could go find a debug pkg and get a
$ rpm -qf /sbin/iwlist
why are both these archs installed?
314/1352 pkgs are i386 or i686 (3 of which are i686)
104/1352 pkgs are noarch
933/1352 pkgs are x86_64
and the last is gpg-pubkey-1ac70ce6-41bebeef.(none) (bug 238332)
metacity-devel-2.18.0-2.fc7.i386 - is the only non-duplicate of the i?86 pkgs,
for all the others there is a corresponding x86_64 pkg.
is this news to anyone that there are so many 'duplicate' non-lib i386 pkgs on a
i'll attach a list of all the i?86 and their coresponding x86_64 pkgs
Version-Release number of selected component (if applicable):
f7t4 dvd fresh install + office, devel, web server + no customize + pup updates
saw this with earlier test releases too
Steps to Reproduce:
1. fresh install x86_64 DVD to device (happens to be Core 2 duo)
2. add following line to .rpmmacros
for i in ` rpm -qa | grep -Ee '\.i.?86$'|sort `; \
do rpm -qv `echo $i|sed -e 's/\.i86$//'`; done
note the many non-lib pkgs that have dups (attached)
would not expect any dup binary pkgs.
Created attachment 153933 [details]
list of i86 and x86_64 pkgs installed on 64bit machine
Many of them contain libraries that someone could develop against. This is
exactly how things are supposed to work
ok Jeremy, thank you sir...
- hopefully this can be a place holder to explain this
- even the binary pkgs not named lib<blah> can contain libs
- but it is confusing that they also contain the same binaries
$rpm -ql subversion-1.4.3-4.x86_64
$rpm -ql subversion-1.4.3-4.i386 | grep bin