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.
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.
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.
I believe this is actually a yum problem; anaconda just inherits the behaviour. Refiling accordingly.
Any progress on this? Would be good to have it fixed in time for the very first F8test release.
A rawhide install today still suffers this problem -- many packages for the secondary architecture are installed when they needn't be.
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.
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 ...
> Even with yum-basearch installed the groupinstall/update installs unwanted > packages. Not surprising, given this in the plugin: if cmd[0] != "install": return
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.
How do I do that for the install? That's when the problem is at its worst. Perhaps we should make this the default?
Josh Boyer is doing a test to see if we want to make it the default or not on ppc.