Bug 235756 - Anaconda/yum installs unwanted packages of secondary arch
Summary: Anaconda/yum installs unwanted packages of secondary arch
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: yum-utils
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: James Antill
QA Contact:
URL:
Whiteboard:
Depends On: 235755
Blocks: multilib
TreeView+ depends on / blocked
 
Reported: 2007-04-09 22:53 UTC by David Woodhouse
Modified: 2018-04-11 13:55 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-03-13 13:27:06 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description David Woodhouse 2007-04-09 22:53:34 UTC
On a default install, we shouldn't install development packages for the
secondary architecture. It's _very_ abnormal for people to want to _develop_ for
the secondary architecture. And it's unlikely to work well anyway, because most
use of autocrap screws up anyway. There's a _reason_ we build our packages in a
non-multilib buildroot.

These packages are unwanted by most people -- I think the only real reason we
have for doing is that RPM screws up the dependencies, so 'yum install
firefox-devel.i386' wouldn't actually pull in all the required i386 packages
because some of the deps would get wrongly satisfied by x86_64 packages. That's
bug #235755.

Comment 1 Jeremy Katz 2007-04-10 14:28:17 UTC
The name of the game is consistency and there actually are a lot of people that
want to be able to have secondary arches Just Work (tm).  Which they do.  Except
for firefox.ppc64 which doesn't work because the provided patch was incomplete
and yet still applied even though it didn't work.

Changing the entire logic of how the installer works just because you can't get
one package working seems kind of broken.

Comment 2 David Woodhouse 2007-04-10 14:41:00 UTC
No, really they don't. Building secondary-arch packages which use autoconf is
very prone to failure -- and most stuff uses autoconf these days. As I said,
there's a _reason_ we use single-arch buildroots.

I don't know why you mention firefox, since that was a completely different
problem (although it is one of many packages which does have the problem I'm
talking about -- it's very hard to persuade the secondary-arch version to build
in a multilib system)

I'm not averse to having an _option_ for installing devel packages for the
secondary arch. But it's a very strange default. Please reconsider.

As for consistency...

pmac /home/dwmw2 $ file /usr/bin/* | grep -c 64-bit
114
pmac /home/dwmw2 $ file /usr/bin/* | grep -c 32-bit
2054

And that's _after_ I've cleaned it up by removing a bunch of 64-bit packages
which weren't required. _None_ of them were wanted 64-bit, except for gdb.

Admittedly, once we fix bug 235757 the mess in /usr/bin should be gone anyway so
this bug becomes less of a problem -- but still, developing for the secondary
arch really is an esoteric requirement, and it's one which can be satisfied by
an _option_; perhaps a group which you choose in the installer or even which you
install later. It really shouldn't be the default. 

Comment 3 David Woodhouse 2007-04-25 15:18:58 UTC
I believe this is actually a yum problem; anaconda just inherits the behaviour.
Refiling accordingly.

Comment 4 David Woodhouse 2007-07-05 03:27:25 UTC
Any progress on this? Would be good to have it fixed in time for the very first
F8test release.

Comment 5 David Woodhouse 2007-09-18 14:16:46 UTC
A rawhide install today still suffers this problem -- many packages for the
secondary architecture are installed when they needn't be.

Comment 6 Matthew Miller 2007-09-23 12:45:17 UTC
Note that there's a simple plugin (yum-basearchonly) in yum-utils to work
towards this behavior, but it needs a lot of work. People who are interested in
this should work on it.

I'm going to reassign this to yum-utils, because if anything is going to happen
here, that's where it will be. After the plugin is done and polished, we can
talk about whether it should be the default behavior and ultimately merging that
behavior back into yum.

In the meantime, less talk, more code. 

Comment 7 Christoph Wickert 2007-12-13 01:53:22 UTC
Even with yum-basearch installed the groupinstall/update installs unwanted packages.

# rpm -q yum yum-basearchonly
yum-3.2.8-2.fc8
yum-basearchonly-1.1.8-1.fc8
#rpm -qa --qf %{NAME}-%{VERSION}-%{RELEASE}-%{ARCH}\\n \*xf\* | grep i386
libXxf86vm-1.0.1-4.fc8-i386
libXxf86misc-1.0.1-4.fc8-i386

(so I have no i386 xfce packages installed)

# yum --enablerepo=updates-testing groupupdate XFCE
Loading "basearchonly" plugin
...
Dependencies Resolved

=============================================================================
 Package                 Arch       Version          Repository        Size 
=============================================================================
Installing:
 Thunar                  i386       0.8.0-3.fc8      fedora            5.2 M
 xfce4-session           i386       4.4.1-2.fc8      fedora            509 k
 xfprint                 i386       4.4.1-2.fc8      fedora            584 k
Installing for dependencies:
 exo                     i386       0.3.2-3.fc8      fedora            679 k
 libxfce4mcs             i386       4.4.1-3.fc8      fedora             46 k
 libxfce4util            i386       4.4.1-3.fc8      fedora             73 k
 libxfcegui4             i386       4.4.1-3.fc8      fedora            277 k
 xfce4-panel             i386       4.4.1-4.fc8      fedora            530 k
...


Comment 8 Matthew Miller 2007-12-13 02:03:54 UTC
> Even with yum-basearch installed the groupinstall/update installs unwanted
> packages.


Not surprising, given this in the plugin:

        if cmd[0] != "install":
                return



Comment 9 Seth Vidal 2008-03-13 13:27:06 UTC
we've implemented multilib_policy as a config option in yum 3.2.11 and above.

If you set it to 'best' then yum will behave as you want.

Comment 10 David Woodhouse 2008-03-13 16:33:07 UTC
How do I do that for the install? That's when the problem is at its worst.
Perhaps we should make this the default?

Comment 11 Seth Vidal 2008-03-13 18:27:28 UTC
Josh Boyer is doing a test to see if we want to make it the default or not on ppc.


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