Bug 235752 - (multilib) Our multilib support is a half-arsed hack and should be a lot less painful
Our multilib support is a half-arsed hack and should be a lot less painful
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Bill Nottingham
:
Depends On: 127359 171743 209306 212522 214737 233145 233427 235524 235755 235756 235757 235758 238374 243224
Blocks: F10Target
  Show dependency treegraph
 
Reported: 2007-04-09 18:39 EDT by David Woodhouse
Modified: 2014-03-16 23:06 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-01 23:14:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Woodhouse 2007-04-09 18:39:23 EDT
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}'.
Comment 1 Warren Togami 2007-04-19 14:03:50 EDT
> 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.
Comment 2 David Woodhouse 2007-04-19 14:36:09 EDT
(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.
Comment 3 David Woodhouse 2007-04-19 14:51:20 EDT
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}'.

Comment 4 Jeff Johnson 2007-04-24 08:04:04 EDT
> 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).
Comment 5 David Woodhouse 2007-04-24 08:22:49 EDT
(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
Comment 8 David Woodhouse 2007-08-11 02:05:00 EDT
(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.
Comment 9 Will Woods 2008-03-27 15:00:22 EDT
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).
Comment 10 Bug Zapper 2008-05-13 22:45:10 EDT
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
Comment 12 Bill Nottingham 2008-12-01 23:14:28 EST
Large changes are unlikely to happen at this point - most of the dependent bugs have been fixed.

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