Bug 238693 - many non-lib pkgs installed i386 on x86_64
many non-lib pkgs installed i386 on x86_64
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Anaconda Maintenance Team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-02 08:07 EDT by das_deniz
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-02 11:39:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
list of i[36]86 and x86_64 pkgs installed on 64bit machine (17.54 KB, text/plain)
2007-05-02 08:07 EDT, das_deniz
no flags Details

  None (edit)
Description das_deniz 2007-05-02 08:07:03 EDT
Description of problem:

i was looking for iwlist pkg owner - so i could go find a debug pkg and get a
backtrace.

$ rpm -qf /sbin/iwlist
wireless-tools-28-2.fc7.i386
wireless-tools-28-2.fc7.x86_64

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
x86_64 machine?

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

How reproducible:

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

%_query_all_fmt %%{name}-%%{version}-%%{release}.%%{arch}

3. run 

for i in ` rpm -qa | grep -Ee '\.i.?86$'|sort `; \
  do rpm -qv `echo $i|sed -e 's/\.i[36]86$//'`; done

Actual results:

note the many non-lib pkgs that have dups (attached)

...
sqlite-3.3.13-1.fc7.x86_64
sqlite-3.3.13-1.fc7.i386
startup-notification-0.9-1.fc7.x86_64
startup-notification-0.9-1.fc7.i386
subversion-1.4.3-4.x86_64
subversion-1.4.3-4.i386
valgrind-3.2.3-2.x86_64
valgrind-3.2.3-2.i386
...


Expected results:

would not expect any dup binary pkgs.

Additional info:
Comment 1 das_deniz 2007-05-02 08:07:04 EDT
Created attachment 153933 [details]
list of i[36]86 and x86_64 pkgs installed on 64bit machine
Comment 2 Jeremy Katz 2007-05-02 11:39:17 EDT
Many of them contain libraries that someone could develop against.  This is
exactly how things are supposed to work
Comment 3 das_deniz 2007-05-02 13:14:27 EDT
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
/etc/subversion
/usr/bin/svn
/usr/bin/svnadmin
/usr/bin/svndumpfilter
/usr/bin/svnlook
/usr/bin/svnserve
/usr/bin/svnsync
/usr/bin/svnversion
...

$rpm -ql subversion-1.4.3-4.i386 | grep bin
/usr/bin/svn
/usr/bin/svnadmin
/usr/bin/svndumpfilter
/usr/bin/svnlook
/usr/bin/svnserve
/usr/bin/svnsync
/usr/bin/svnversion

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