[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Proposed pre-depends addition: all multiarched libs -> multiarch-support

Hi folks,

One of the things that held up the deployment of multiarch-friendly library
packages in Debian was the recognition that the host triplet used on i386,
i486-linux-gnu, was not suitable for cross-distro standardization because it
encodes information about the current default optimization that we've chosen
for our toolchain.

After much soul-searching, a solution has been agreed upon that will let us
use i386-linux-gnu as the multiarch path component on i386.  This solution
should be codified shortly in Debian policy via bug #619186, and it has been
signed off on by the dpkg, eglibc, and gcc maintainers.

Now the trouble is that, owing to a case of poor timing, neither the gcc nor
the eglibc in squeeze supports looking in /lib/i386-linux-gnu - they only
support looking in /lib/i486-linux-gnu.  So any library that is unpacked to
/lib/i386-linux-gnu becomes invisible to ld.so unless a newer ld.so is
unpacked first.  And since Depends only guarantees configuration order, not
unpack order, that means Pre-Depends... for every library that is migrated
for multiarch.

Specifically, the plan is that any package in wheezy shipping a runtime
library in a multiarch directory should declare a Pre-Depends on the
metapackage 'multiarch-support'.  This package will be built from eglibc
source, and for each architecture it will depend on the appropriate version
of libc that implements support for the corresponding multiarch lib

I'm reasonably confident that we have this right, having discussed this with
the release team and tested it under "live fire" in Ubuntu; but as Jonathan
Nieder rightly points out in the policy bug, policy asks for Pre-Depends to
be discussed on debian-devel, not just on debian-release.

Does anyone see a better way to achieve this result, that I've overlooked? 
Will adding this pre-depends on multiarch-support cause any problems that we
haven't yet identified?

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[1] For those who care, this is not being done with a virtual package
because that creates an unsolvable pre-depends loop between libc6 and
libgcc1 of the *foreign* architecture the first time you try to install
multiarch; making this a real package lets us break the loop for the foreign
architecture.  It also has the side effect that multiarch-support can have
an appropriate versioned dependency on libc for each architecture, so that
on !i386, it's installable against the squeeze libc in a partial upgrade.

Attachment: signature.asc
Description: Digital signature

Reply to: