Hi Michael Tsang (and hi d...@l.d.o) 2010/6/24 Michael Tsang <mikl...@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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinjwuf_ptvymcwrulur2zjy2ie2knseddluv...@mail.gmail.com
