Handling multilib

David Woodhouse dwmw2 at infradead.org
Tue Mar 20 09:17:33 UTC 2007


On Mon, 2007-03-19 at 08:20 -0400, Jesse Keating wrote:
> On Sunday 18 March 2007 14:50:06 David Woodhouse wrote:
> > Ideally, I think we want a new RPM tag for it, and it can be specified
> > in the specfile. The package author can then specify whether the package
> > should be shipped for the secondary arch (i386 on x86_64, or ppc64 on
> > ppc64), and even whether the secondary version should be _favoured_
> > (64-bit gdb on ppc64).
> 
> Unfortunately multilib isn't well understood by a large majority of our 
> maintainers, both inside RH and without.  Leaving it up to the maintainer is 
> pretty much going to result in the vast majority of packages not being 
> multilib, especially the first time a multilib problem is found, boom, 
> multilib off rather than fixing the problem.

I agree that if we give more control to the package maintainer, there is
a risk of them taking the easy and wrong way out of any situation --
just like the abuse of ExcludeArch when a packagemonkey can't be
bothered to fix a problem. In practice, our maintainers aren't _so_ bad,
and it's relatively simple to keep the use of ExcludeArch in check. I
don't think it would be impossible to keep multilib stuff in check too.

I'm not entirely sure how "multilib off" would work; we always end up
building for both architectures; the question is what happens when you
need both versions installed. The packagemonkey can't just turn that
_off_, surely?

In fact there are a number of questions related to multilib...

1. Do we build this package on both architectures?

   I think the answer for this wants to continue to be "yes" in all
   cases, as you said.

2. Do we ship both versions of this package in the default install?

   For gdb, kernel, glibc "yes". For just about everything else,
   probably not. Only if you ask for development packages should you
   get the mess of -devel packages in both versions. And possibly only
   then if you specifically ask for development packages for the
   secondary architecture.

3. Do we _install_ both versions of this package by default, either
during installation or upon 'yum install foo'? Or do we install the
primary architecture version alone? The secondary architecture alone?
The 64-bit version alone? The 32-bit version alone?

   For gdb on 64-bit machines we always want the 64-bit version.
   For kernel we want the one which matches the hardware -- kernel is a
   special case, really. For most things we want _just_ the primary
   architecture (ppc/x86_64). For glibc we want both simultaneously.
   Development packages probably also just primary, although you can
   make an argument for installing both versions in parallel.

4. When we install both versions in parallel and there are conflicting
files, what do we do? Refuse to install it? Let files for primary arch
override secondary? Let files for 64-bit override 32-bit?

   Currently, RPM is has hardcoded exceptions so that it can install
   packages with conflicting files. When there are different executables
   it'll choose the 64-bit one, even on ppc64 where the 32-bit one is
   the "primary arch" and would usually be the better choice. So we end
   up with a mix of 32-bit and 64-bit executables in /usr/bin.

   There are those who would argue that we  should allow "conflicting"
   files only when they're identical -- not for executables. Thus we
   should split executables and libraries into separate packages, so
   that the libs can be installed in both flavours while the executables
   may only be installed in one version at a time.

   That makes sense to me -- the alternative is to just screw around a
   little more with RPM's hardcoded behaviour, which seems wrong.

> Add to that the confusion of "Hey, I set my package to not be multilib, why is 
> it landing in the tree as multilib" when we bring things in due to deps of 
> some other package that was marked as multilib.

Er, did we fix the deps so that we actually pull in foo.ppc64 when
bar.ppc64 requires 'foo'? Or do we still let foo.ppc "satisfy" that
dependency? :)

> These are just a couple of problems I see with leaving it up to the 
> maintainer. 

Both of which involve the simple "multilib off" option, and the
assumption that the packagemonkey would be permitted to abuse it. I do
understand and share those concerns to a certain extent, but based on my
experience with chasing up usage of ExcludeArch I think we can keep it
in check quite happily.

>  Not that there aren't problems with the way it is done now, but 
> at least there we can typically blacklist something (if it isn't brought in 
> by deps) or re-adjust the packaging to make it more sane.  Firefox was a 
> rather unique situation and an unfortunate outcome, but I don't think it is 
> fair to base the entire multilib experience on Firefox ppc64, something which 
> extremely few of our users would have seen/experienced.

I spoke of firefox as a recent example, but it certainly wasn't the
majority influence in my thinking.

How we handle tagging multilib in the package itself depends on what we
do with RPM -- do we make it stop silently resolving conflicts on
executables? That seemed to be the consensus when it was discussed
briefly on IRC; nobody really spoke up for the status quo. So I'll work
on that assumption; we can backtrack if necessary.

That means we have to have a separate subpackage for libraries vs.
executables in the case where we want the libraries to be available
multilib.

We could add a 'Multilib' tag to each binary RPM, with four possible
values: "primary", "secondary", "64bit", "32bit", "parallel". OK, five
values.

The first four options would mean that the package should be installed
only for one architecture depending on the hardware. Packages marked
'64bit' or 'secondary' would be shipped in both forms in the ppc
compose, and packages marked '32bit' or 'secondary' would be shipped in
both forms in the x86_64 compose.

Packages marked 'parallel' should be shipped in both forms -- and that
would cover most of the libraries and -devel packages. It should be
relatively simple to do a pass over package CVS adding those tags
according to our current heuristic, in fact.

Whether the installer or yum actually _installs_ both versions of a
package marked as 'parallel' is a different question -- I suspect it
should be optional. Some users might want it; most won't.

This means that in the normal case a 'foo' package would be marked
'primary', while 'foo-libs' and 'foo-devel' are marked 'parallel'. I
wonder if there's some way we can make that work by default without
making the user explicitly tag it? Perhaps we can default to 'parallel'
but switch to 'primary' if there are any files in %_bindir? Or
something?

-- 
dwmw2




More information about the Fedora-maintainers mailing list