Re: Breaking /emul/ia32-linux for squeeze
Steve Langasek <vorlon@debian.org> writes:
> 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
Is that even true? /lib32 and /usr/lib32 are system library paths
while the multiarch dirs are custom paths added via
/etc/ld.so.conf.d/x86_64-linux-gnu.conf. I think they come last.
Assumptions:
- there is no biarch, we choose pure64.
- multiarch will add support to run 32bit libraries
Obviously they haven't been strictly true for some time now. But it was
always just a verry minor proportion of packages with biarch so having
to add a conflicts or not was never thought of as a problem. At first
it even was just ia32-libs but then packages started to split of over
time and migrated to stable. It was never ment to take this long.
> 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.
Then any old programm might break. And you know how long 3rd party
packages stay around.
>From the package management point of view: When you add multiarch and
drop lib32* packages then the libraries move from lib32foo to libfoo
(i386). Idealy we would have libfoo (i386) Replace/Conflict/Provide
lib32foo so both old and new programs work. But no versioned
provides. A lib32foo dummy package that Depends on libfoo (i386) could
be added to smooth the transition.
Either way when libfoo (i386) gets installed lib32foo should get
removed automatically to avoid any possible screwups. Even if they
don't conflict. I don't want to find out 2 years down the line that an
ABI transition blows up due to lib32foo packages on the users system.
MfG
Goswin
Reply to: