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. 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/ firstname.lastname@example.org email@example.com  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.
Description: Digital signature