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 directory.[1] 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? Thanks, -- 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/ slanga...@ubuntu.com vor...@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.
signature.asc
Description: Digital signature
