Witness clean FC6 install on PPC64. It installs a whole bunch of 64-bit userspace crap which the user _really_ doesn't want, because there's no point in the bloat of 64-bit on an architecture which had a sane number of registers in the first place. And it installs a 32-bit kernel. Multilib doesn't have to be as painful as we've made it. We have a bunch of crappy heuristics like the 'does it have a -devel subpackage' one for whether to ship multilib. That was a fine hack for the first prototype, but after the first five minutes it's obvious that it's a crappy half-arsed hack. Allowing conflicting binary files in /usr/bin is also a hack. We should have just fixed the packages. If you have both binaries and libraries, and you want the libraries to be available for both architectures, then split the package into 'foo' and 'foo-libs'. We shouldn't be installing all these -devel packages for the secondary architecture in a standard install either. Building for something other than the primary architecture is not only a _massively_ esoteric requirement, but it's also highly unlikely to ever work with packages which make the mistake of using autotools, anyway. As far as I can tell, the only reason for doing it is because our dependencies are so broken that we can't install the secondary arch packages later -- because if 'foo-devel' requires 'bar-devel', then 'foo-devel.i386' will be satisfied by the existence of 'bar-devel.x86_64'. We need to fix the fact that RPM doesn't allow "Requires: foo.%{arch}'.
> As far as I can tell, the only reason for doing it is because > our dependencies are so broken that we can't install the secondary arch packages > later -- because if 'foo-devel' requires 'bar-devel', then 'foo-devel.i386' will > be satisfied by the existence of 'bar-devel.x86_64'. I am pretty sure this is incorrect.
(In reply to comment #1) > I am pretty sure this is incorrect. Since I'm fairly sure the dependency errors aren't a figment of my (admittedly deranged) imagination, I suspect you're referring here to the reasoning for shipping the unwanted secondary-arch development packages. In that case, you neglected to actually _mention_ any other reason for shipping these packages -- which, remember, aren't sufficient to build most non-trivial packages for the secondary arch _anyway_. Anyway, this discussion is probably best continued in bug #235756 rather than here in the tracker bug.
IRC discussion confirms you were actually disputing the existence of the dependency errors. In which case see bug #233427, in particular https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=233427#c11 It's often wrong for BuildRequires: too. Often when I try to build a 64-bit package I find that I need to manually install -devel packages because the 32-bit version of the foo-devel package satisfies the 'BuildRequires: foo-devel' which should have been 'BuildRequires: foo-devel.%{ARCH}'.
> It's often wrong for BuildRequires: too. Often when I try to build a 64-bit > package I find that I need to manually install -devel packages because the > 32-bit version of the foo-devel package satisfies the 'BuildRequires: foo-devel' > which should have been 'BuildRequires: foo-devel.%{ARCH}'. Can you provide an explicit example where you "need" to manually install a 32bit (rather than 64bit) version to satisfy a BuildRequires:? Sure, installing a 32bit version will satisfy the dependency, not at all the correct thing to do (I'm sure we agree on that).
(In reply to comment #4) > Can you provide an explicit example where you "need" to manually install > a 32bit (rather than 64bit) version to satisfy a BuildRequires:? http://david.woodhou.se/bloodyobvious.spec
(In reply to comment #7) > (I don't agree with the language or wording of this bug, however). I just want > to state that too - I agree with the points, but I prefer to keep this > discussion purely technical. The current multilib implementation needs fixing. I seriously disapprove of private comments on Fedora bugs. But since you explictly state that (for some reason) you don't want to comment publicly, I suppose I have to respond privately too. The 'half-arsed hack' assessment is an entirely correct technical assessment of the situation. Feel free to change it if it really bothers you. The text of this bug isn't really important though -- it's the dependency tree which matters.
We're not doing this for F9, apparently. Moving to F10Target. If we get an accepted Feature for this, it should go to F10Blocker. Or the blocker for whatever release is current when we get around to doing this (it was originally targeted at F8).
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Large changes are unlikely to happen at this point - most of the dependent bugs have been fixed.