On Thu, Feb 24, 2011 at 12:03:18AM +0100, Andreas Barth wrote: > * Steve Langasek (vorlon@debian.org) [110223 22:53]: > > 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. > Or third, we could add the new path to eglibc in a stable point > update and into unstable, and either > a) have a virtual package provided, and for the core utilities > pre-depend on that virtual package (so that user systems are never > broken by the upgrade), or > b) don't multiarch the core utilities for the next stable release. b) doesn't help. This is about libraries changing location and making sure that they're on the runtime linker's path; this will affect every core library on the system and there's no way to except the core /utilities/ from that. (If you want a multiarch X stack this cycle, you need a multiarch zlib. Guess what depends on zlib? :) A virtual package is a good idea, though - in fact, it's such a good idea that I remember now we discussed this back at DebConf and I'd subsequently forgotten about it. Thanks for jogging my memory! :) Yes, whether or not we add support in a stable point release, I think that if we don't go the dpkg-shlibdeps route we should use a 'multiarch' or 'multiarch-foo' virtual package. -- 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