Re: Multi-arch

["Ludovic Brenta" <ludovic@ludovic-brenta.org>]

> Yes, it can be done and is very well worth it. On Gentoo it is called
> multilib and is supported distribution-wide, not only for x86 and
> amd64, but ppc and sparc have theirs multilibs too IIRC (I think both
> of them, but may be only sparc actually).  gcc is supported, as well
> as Ada and most of the libs and apps (to the point where you can
> have wine running 32-bit Windows code on otherwise
> 64bit-clean system - kernel and userspace).

Interesting. I've looked at multilib.eclass and gnat-gcc-4.1.0.ebuild.
I have no detailed knowledge of the Gentoo portage system, so I can
only guess, but it seems to me that the current infrastructure means
that each source package builds several binary packages, one for each
arch, on the machine where you build.  So, for example, if you have an
amd64 machine, you'd get two binaries, i386 and amd64. Furthermore, the
i386 package would install libraries in /usr/lib32, whereas the same
package built on a i386 machine would install libraries in /usr/lib, so
the two packages would be slightly different, and incompatible, even
though built for the same architecture. Debian is currently in a
similar situation, except that it has not deployed this scheme
distribution-wide but only in a few important packages, binutils and
gcc being the most prominent ones.

In the proposal, a source package would only produce one binary package
for the machine doing the build; thus your amd64 box would only produce
the amd64 binary. Then, if you want to install the i386 binary as well,
you'd take the package built by the i386 autobuilder, modify it on the
fly (this is one of the proposed changes to dpkg), and install it
alongside your amd64 package.

Of course, this scheme only makes sense in the context of a binary
distribution like Debian, but there are several benefits:

- it reduces the workload of the autobuilders
- it reduces the size of the binary distribution, and load on the
mirrors
- it simplifies system administration
- it simplifies the job of package maintainers and reduces the
opportinuties for bugs

>From what I understand, Gentoo people might not be very interested in
these benefits, because:

- Gentoo has no autobuilders, as each user recompiles the world on
their machine
- Gentoo has no binary distribution apart from the minimal
bootstrapping system
- Gentoo users seem to like system administration :)
- Gentoo package maintainers seem to like difficult problems :)

The proposal also hints at the LSB. I think it would be necessary to
standardise the library paths across all distros. The current /usr/lib,
/usr/lib32, and /usr/lib64 directories are not general enough. Consider
that some HP processors can run i386, amd64, ia64, hppa *and* hppa64
binaries on the same machine :) And what about Cell processors and
other future asymmetric multiprocessors? What about binaries intended
to run on GPUs or other coprocessors?

> you can catch me on irc,freenode.net in channels #gentoo and
> #gentoo-dev if you would like to discuss this further (my nick there
> is georges, email of course works too: george at gentoo.org)

I'd rather keep the discussion here on c.l.a as it it not specific to
Gentoo, or Debian, or any particular distribution.

-- 
Ludovic Brenta.