Re: Improve support for installing 32-bit libraries on 64-bit systems
Hi Michael Tsang (and hi d-d@l.d.o)
2010/6/24 Michael Tsang <miklcct@gmail.com>:
> I have a recommendation for 32-bit libraries on 64-bit systems:
>
> Now, some libraries are available on 64-bit systems as lib32* but these are
> very few. To improve this situation, I think that we can organise the library
> packages as follows:
Some problems with this approach are:
a) we have multiple 32-bit architectures - i386, arm(el), mips(el), …
and even hurd-i386 and kfreebsd-i386 so the naming is ambitious.
a1) if you name the packages differently you need to add A LOT of
alternatives depending on the architecture to the dependency lines.
This not only complicates all these lines but make it also harder to insert
new libraries and/or archs as they will slowly propagated in the pool.
(Beside that i am not complete sure that an arch depending alternative
option is even allowed currently: Depends: lib | lib32 [amd64 sparc64] )
a2) with a different name you avoid the file "conflicts" in at least
/usr/share/doc/ - aka changelog, copyright and stuff -- but do they really
differ for the same library which is just build for different architectures?
So you have a lot of duplicates, right?
b) a lot of "duplicated" packages are created: In which way will lib:i386
differ in your (and current) approach from lib32:amd64 expect of the name?
c) These lib32, ia32, whatever42 packages tend to be a hell to maintain…
(how big is the "source" of ia32-libs currently, 370 MB ? Just a library? *)
d) what will happen with the release of a 96bit or 128bit architectures?
> This should be implemented as a build template to make all library packages
> use this organisation scheme. I think this should be implemented after the
> release of Squeeze.
If you look closer, MultiArch was at least for squeeze on the goal list.
I guess it is pretty unlikely that we will make it, but i think it was more
on the list to get a bit of noise and some progress -
and some progress is visible.
The biggest showstoppers are as far as i know that
a) dpkg doesn't support it
b) APT doesn't support it
c) (not many) packages use it (last time i check ~24)
c) is likely caused by a) and b) which in fact decreases the motivation for
a) and b) to implement it as nobody use it… *** dependency loop detected ***
But don't worry, Debian has found a victi… äh, i mean a volunteer to work
on b) [0] - and the good thing is, you can even try and play with it already -
you just need an apt/experimental build (, a bit of luck) and the right
configuration options. See also README.MultiArch, but <insert the usual
experimental is called experimental for a reason warning here>
(yes, correct, shameless self-advertisement).
Best regards,
David Kalnischkies
[0] http://wiki.debian.org/SummerOfCode2010/APT-MultiArch/DavidKalnischkies
which is an accepted proposal and implements it according to the
https://wiki.ubuntu.com/MultiarchSpec
* yes, that are trick questions.
Reply to: