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

RFC: use of shlib bump for libc dependency on new multiarch directories?

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?

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

Reply to: