Dear release team, Although the paths in which libraries will ultimately be installed for multiarch is not yet entirely settled, one thing that is clear is that on i386, we almost certainly will not be using the path which has been enabled in glibc up to now, namely /lib/i486-linux-gnu.[1] We will most likely be using either /lib/i386-linux-gnu or /lib/x86-linux-glibc instead, depending on the outcome of various ongoing discussions; and libraries installing to either one of these paths are going to need to make sure the new libc is installed first, or they'll instantly become unavailable on upgrade. We can handle this one of two ways. We can either bump the minimal dependency of *all* packages against libc, by adjusting shlibs/symbols in the eglibc package; or we can make adding the dependency a part of the standard library multiarchification recipe. The first approach means that every library on the system will depend on the new libc as soon as it's rebuilt, whether or not it's installed to the multiarch library path. However, my handwavy estimate is that by the time wheezy is out we should have better than 80% library coverage with multiarch, so maybe that's not an issue at all. But it also may not be sufficient to ensure smooth upgrades either; dependencies don't guarantee unpack order, so what happens if a library needed by apt+dpkg to finish the unpack of the new libc gets disappeared out of the system path before libc itself gets unpacked? do we need to special-case the addition of pre-depends to any libraries that are needed by the package manager? Do we want pre-depends for *all* libraries, just in case? The second approach is going to be more error prone; it's one more step that has to be added to the process for converting a library package to multiarch, which means it's one more step that maintainers can forget and one of the easiest to go unnoticed for long periods in unstable/testing. We could mitigate this somewhat by having debhelper do something here by default when it sees multiarch paths in use, but that won't give us 100% archive coverage either (and oh, how the work I've been doing on my multiarch proof-of-concept bootstrap makes me wish it would :-). It also isn't viable anywhere we decide we need Pre-Depends, since most packages simply won't have a substitution in place for Pre-Depends that debhelper can hook into. Since this is an issue with high potential impact on squeeze->wheezy upgrades, Aurélien suggested that we solicit input from the release team here. Do you guys have any recommendations on how we should handle this, or any other concerns that I may have overlooked? 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/ slangasek@ubuntu.com vorlon@debian.org [1] i486 is an arbitrary name that happens to correspond to the base instruction set that was in use on Debian at the time multiarch was first formulated, but it doesn't match the current base instruction set on Debian (i586) or Ubuntu (i686), doesn't match the directory configured in the current eglibc package on Ubuntu (/lib/i686-linux-gnu), and is going to look weird to other distributions when we try to talk to them about this since they've also long since moved to i686 as their base compatibility.
Attachment:
signature.asc
Description: Digital signature