On Wed, Feb 23, 2011 at 10:55:51PM +0000, Simon McVittie wrote:
> On Wed, 23 Feb 2011 at 13:52:35 -0800, Steve Langasek wrote:
> > we almost certainly will not be using the path which has been enabled
> > in glibc up to now, namely /lib/i486-linux-gnu.
> I'd heard that, and was somewhat concerned about whether that'd block
> multiarch for yet another release cycle; I'm glad to hear it isn't.
> One possibility that occurred to me is adding a Pre-Depends on a new package
> ("multiarch-enabler", perhaps) which is arch:any and just contains this
> file:
> # /etc/ld.so.conf.d/x86-linux-glibc.conf
> /lib/x86-linux-glibc
> /usr/lib/x86-linux-glibc
> Am I right in thinking that (probably only needed for the native architecture,
> even) would be enough to "bootstrap" support for the multiarch paths in the
> native architecture's linker far enough to perform the upgrade? A future
> libc6 could even Replace it or something.
> (It'd be a bit subtle by being transitively Essential, though.)
Currently I don't see any advantage of doing it this way, rather than having
libc provide this file directly and have affected package pre-depend on
libc. The only reason we might consider a separate binary package closer to
release is if we wind up with circular dependencies that break upgrades from
squeeze; so this is a good idea to keep in our back pocket as a fallback
plan, but until it's shown to be needed I think it's unnecessary complexity
that we should avoid.
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
Attachment:
signature.asc
Description: Digital signature