Bug 145747 - exactarch is braindead
Summary: exactarch is braindead
Alias: None
Product: Fedora
Classification: Fedora
Component: yum   
(Show other bugs)
Version: 3
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-01-21 01:57 UTC by Thomas Walker
Modified: 2014-01-21 22:51 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-24 19:29:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Thomas Walker 2005-01-21 01:57:57 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.7.3)
Gecko/20041020 Firefox/0.10.1

Description of problem:
I've read a lot of various posts about how "exactarch" is intended to
only apply for updates, not installs, but this logic is really broken.
I have an x86_64 system and I only really want the ia32 libraries that
I *really need* to support some binary only apps.
Problem is, when I go to install a new app for which a perfectly valid
x86_64 version is available, yum tries to install loads of ia32 deps
in order to install the ia32 version of the binary as well (which I
don't want anyway).
I understand the original intention of this flag but feel that it is
ineffective for most user's needs (how many people really want 32 and
64 bit versions of *every* app installed?)
Can you please push upstream to expand this option (or add another
one) that actually applies to installs unless explicitaly (ie. "yum
install foo.i386") asked for?

Note: I'm classifying it as a bug rather than a feature enhancement
because, from reading the manpages, it reads like exactarch should
work as I describe.  This is something that is going to drive new
users crazy and *needs* to be fixed.

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

How reproducible:

Steps to Reproduce:
1.yum install (some new app)

Actual Results:  yum tries to install both i386 and x86_64 app and deps

Expected Results:  yum only tries to install the arch I choose (by yum
config option) unless overridden with "yum install foo.<other arch>"

Additional info:

personal (not work related, despite the email), not that it should matter.

Comment 1 Seth Vidal 2005-01-21 02:13:27 UTC
1. you'll find that you'll get a lot farther with bug reports if
you're comments are less incendiary and more constructive. Calling
something braindead isn't helpful it's just rude.

2. exactarch isn't considered during an install operation. what is
considered is the best available arches for multilib arch trees. yum,
when you do not specify the arch you want to install, will try to
install the best possible arch for your system. On a singlelib arch
this means the best arch for any set of arches available. On a
multilib arch this means the same - but there are two sets of arches
we look through. 32bit and 64bit. That's what is going on.

So if you typed: yum install foo.x86_64 - then it would only install
that specific arch.

I've heard the argument for only installing the best of the multilib
arches there, I'm just not sure that for consistencies-sake it makes
sense. Feel free to make your argument more clearly and w/o
pejoratives and I'll think about it.

Comment 2 Thomas Walker 2005-01-21 14:36:10 UTC
My appologies if you think it was rude... I've heard the multilib
arguement before and you'll notice that I explicitely address your
point #2 and the workaround in my post.  I'm not quite sure how
installing two versions of an app and 10 libraries instead of the much
more obvious 1 binary is more "consistent".
I can see how some people might want the behaviour that currently
exists now but it should be configureable.  The default behaviour is
simply not what a lot of people want (try sticking "exactarch install
x86_64" into google and you'll get a couple pages worth of responses
to support my assertion).

Comment 3 Thomas Walker 2005-02-18 16:39:01 UTC
Not to push the point too much, but a very common issue where this
becomes helpful is when you are trying to build from srpm or trying to
install (via rpm) and it tells you you are missing a whole bunch of
packages, without the arch appended.
It is a real pain to go through and add ".x86_64" to all of them to
prevent yum from trying to pull the i386 packages (and their deps) as
One might argue that this is a problem in rpm/rpmbuild but I really do
believe that this would be quite a useful option to some people who
prefer to have an "as close to native" install on their machine (I
wouldn't have any i386 packages if it weren't for the fact that
openoffice still isn't 64 bit clean).

Comment 4 Thomas Walker 2005-03-27 23:59:32 UTC
A return to this... again, sorry if I was rude before.

I just think it would be a very useful option for people on multiarch systems to
be able to say "only my primary arch unless specified otherwise".  Various apps
(rpm and rpmbuild come to mind, actually just about anything that isn't yum)
give package names without the arch suffix which means cut-paste and edit a lot
of stuff so that you don't install the world... would be good if you could make
this a little easier (hell, I'll code it if you want but I would like your
general nod before I go and brush up on python first).

Comment 5 Seth Vidal 2005-03-28 00:22:17 UTC
so how would you test for it?

if someone issues the command:
yum install foo*

how would you know whether they REALLY wanted foo.i386 and foo.x86_64 or if they
just wanted foo*.x86_64?

Show me how I check for it b/c the last thing I want to do is to ignore the
specified arguments on the command line.

and remember, wildcards are allowed in package specification for the command line.

Comment 6 Thomas Walker 2005-05-10 23:28:54 UTC
The whole point was that you should get your default arch unless otherwise
specified.  If you really believe that x86_64 users want to install both 32 bit
and 64 bit apps (which doesn't work btw, there may be /usr/lib and /usr/lib64
but there is only a single /usr/bin) then the "prefered arch" should be
configureable rather than choosing a basically broken approach (install both,
whichever installs first is broken and pulled in lots of libs that won't be used)

Comment 7 Thomas Walker 2005-05-24 19:29:12 UTC
ok, not worth the trouble at this point, I'll just wrap yum and be done with it.

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