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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature