x86_64, i386, and yum

[Andreas Bernauer]

Edwin Huffstutler wrote on Tue, Jul 03 2007 at 06:16 (-0700):
> 
> >From my searching, most of these have been discussed before (several times)
> or have had various bugzillas I think, but I was just wondering if someone
> could sum up any overall action to clean up the situation.
> 
> 
> 1. "yum install foo" installs both foo.i386 and foo.x86_64.  I know this
>     has been hashed out before and declared "not a bug", but does anyone
>     actually like the way this is working?  Yes, there is a good reason for
>     it but the common case on x86_64 seems to be a misfeature.

I agree with you.  You can avoid this by specifying the architecture: 
yum install foo.x86_64

> 
> 2. If yum updates some package that has a *new* dependency that the old
>    version did not have, yum will install both arch versions of the
>    depended-upon package (see above).  When that happens with just one lib,
>    it can by chain-reaction drag in about half of a whole i386 package
>    set.  Whee.  neato.

This does not happen to me when I specify the architecture like in  
yum update rdesktop.x86_64
instead of 
yum update rdesktop

But maybe I was just lucky.

> 
> 3. If you have 2 arches of a package installed, and you "rpm -e" the i386
>    version, any shared files (docs, etc) get removed.  Makes it hard to
>    clean up from either of the above 2.

It does not help you, but the two packages should not have shared some
files in the first place (or even better: put non-executable files
into a noarch rpm).  Especially kde packages seem to not care about
this (kdelibs, kdebase, ...).

Looking at my notes, I think yum should have a real 'exactarch'
option, that only installs packages that are of this architecture.

Andreas.

-- 
http://www.lysium.de/blog
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20070703/dd015c9c/attachment-0001.sig>