Re: Breaking /emul/ia32-linux for squeeze
On Thu, Mar 12, 2009 at 08:52:04PM +0100, Goswin von Brederlow wrote:
> Steve Langasek <vorlon@debian.org> writes:
> > On Thu, Mar 12, 2009 at 11:03:06AM +0100, Goswin von Brederlow wrote:
> >> > What transitional issues is that going to cause us if and when multiarch
> >> > becomes generally available, if biarch packages start using the path now?
> >> libfoo i386 then needs Replaces: lib32foo. But it already needs
> >> Conflicts: lib32foo I think so there isn't really any harm done.
> > No, currently there isn't anything else that would require adding such a
> > conflict.
> When dpkg supports multiarch then you could have libfoo (i386) and
> lib32foo installed at the same time. That would mean that you have
> (possibly) 2 different versions of the same library installed. ld.so
> would then prefer one over the other resulting in either packages
> depending on lib32foo or package depending on libfoo (i386) to use the
> wrong library. A package with "Depends: libfoo (>= 1.2-3)" could
> suddenly get libfoo 1.1-1 (from lib32foo) and crash.
> So to make sure there is only one package providing a specific library
> for an arch the lib32foo and libfoo (i386) packages have to conflict.
That's an arbitrary new requirement that TTBOMK has never previously been
discussed in the context of multiarch.
I think it has always been assumed that:
- multiarch will supersede all previous biarch implementations
- multiarch will be before biarch in the search path
Taken together, this guarantees the newer libs would always be found before
the older libs, so there's no need to do extra special-casing for those libs
that were previously available in biarch form.
--
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
Reply to: