Re: Improve support for installing 32-bit libraries on 64-bit systems
Michael Tsang mikl...@gmail.com writes: 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: For a library with soname libfoo.so.1, we can make the following packages: libfoo1 - /usr/lib/libfoo.so.1 lib32foo1 - /usr/lib32/libfoo.so.1 That would be lib32, lib64, libn32, libo32, lib32el, lib32eb, libn32el, libn32eb, lib64el, lib64eb, ... Need I go on? Also note that you need lib32foo1 on ia64 but you can not compile one. There is no multilib or cross-compiler for i386 on ia64 in Debian. libfoo-dev- /usr/lib32/libfoo.so /usr/lib/libfoo.so /usr/include/foo.h libfoo-dev depends on libfoo1 | lib32foo1 (if one of them aren't installed, left the .so link as a dead link) Which would mean that tons of users would end up with broken symlinks and sources would fail to compile. apt-get build-dep would not work anymore and so on. Verry bad idea. No, you need libfoo-dev and lib32foo-dev and all the other names from above. libfoo-shared - architecture-independent files of libfoo (excluding development files) 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. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html Multiarch solves this much better and includes cross-compile support in this while also avoiding the many multiple of compiles of the same lib. Also ia32-apt-get solved this issue nicely for the time till true multiarch will finally be available. You can pick pretty much any library and apt-get install ia32-libfoo or install 32bit debs directly and apt will resolve the depends just fine. The parts that possibly break in ia32-apt-get are the parts packages must fix to be multiarch compliant. Even if dpkg/apt don't support multiarch then ia32-apt-get could install multiarch package reliably under the prefixed name. But 99% of use cases work just fine already. And don't forget there is a Google summer of code project to multiarchify apt. MfG Goswin -- 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/874ogklmhg@frosties.localdomain
Re: Improve support for installing 32-bit libraries on 64-bit systems
2010/6/26 Luca Bruno lu...@debian.org: David Kalnischkies scrisse: 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 *** Goswin recently offered some help to improve the situation regarding a) and c) points, but I've seen no (public) answer from you: http://lists.debian.org/debian-devel/2010/04/msg00493.html What should i have answered? That i like that he wants to work on a) and c)? I knew that as we exchanged a few mails already as he is also present on deity@ and the associated bugreports, so my only semi-public move as response to this mail was to join the recommend list and proceed in doing stuff rather than writing the obvious… especially as i was not a (direct) addressee of the mail and got it a bit later than usual. I can't comment on a) as dpkg is magic (for me at least) and the problem for dpkg is more about reference counting for /usr/share/doc files than dependency solving as far as i understand and should as it is promised be done by someone who know his stuff. It might need to do something similar to what i did in APT with creating pseudo-archdepending packages for arch:all packages to simplify dependency solving, for their dependency checking but that depends on their liking, isn't limited by compatibility requirements like it is in APT - and the theory is documented in README.MultiArch and code in case i am hit by a bus, so as long as nobody has (further) questions - nothing to comment… c) is also not my cup of tea so far as i never touched a library by now, starting to tell libary maintainers they should do this and that is at least in my understanding a bit awkward then. (This avoids also a bit pre-seeding everyone with my understanding.) ;) Given that you say apt in experimental is semi-working, it would be interesting to join forces and see if something almost test-able can be provided. Semi working as (obviously) nothing can be really installed as dpkg will jump at you if you try. Semi working also as i focused mostly on the case until now that you have e.g. i386 and amd64 packages available but have only packages from one arch installed (fun-fact: It is i386 for me as i have no amd64 system currently). Requesting to install one or two packages from the other arch will be the most seen use case and this works so far, but only with simple constructed cases as in real world you will be hit by c) - i see that positive as this at least guarantees that APT isn't too relaxed about the dependencies. ;) The ABI changes for it are quite stable and i am especially happy that they are API compatible to the SingleArch-epoch. The APT part left is beside bughunting really the (important) MultiArch auxiliary stuff i described in the proposal. If so, it would also be useful to advertise it a bit more and hoping to gain some momentum... While many would certainly love it, i don't feel like rushing into a mess. We already saw some tries to implement a semi-multiarch behavior and personally i don't want to see them again. Do it once, clean and for real - and at best not before squeeze freeze or even release: It requires a lot of changes to work correctly in a lot of packages and mindsets and would be currently a waste of time which could better be spent in (rc-)bugs and ongoing or waiting transitions. (At least in the eyes of my mentor and myself. Big bangs after releases generally generate more (positive) noise than near freeze time) And most of the auxiliary stuff has the advantage to be not only needed for MultiArch, but fixes a lot of bugs in drive-by mode. Thankfully APT has still so many of them to choose from. ;) Best regards, David Kalnischkies -- 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/aanlktiklo0ach_m9lqo0ekxxxfnudepm6vdk_cyrc...@mail.gmail.com
Re: Improve support for installing 32-bit libraries on 64-bit systems
On Fri, Jun 25, 2010 at 01:14:43PM +0200, David Kalnischkies wrote: 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 - That's not why it was put on the list, but unfortunately not as much forward progress was made during the squeeze cycle as intended. -- 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 Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Improve support for installing 32-bit libraries on 64-bit systems
David Kalnischkies scrisse: 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 *** Goswin recently offered some help to improve the situation regarding a) and c) points, but I've seen no (public) answer from you: http://lists.debian.org/debian-devel/2010/04/msg00493.html Given that you say apt in experimental is semi-working, it would be interesting to join forces and see if something almost test-able can be provided. If so, it would also be useful to advertise it a bit more and hoping to gain some momentum... Ciao, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer pgp9Dkea2yZCS.pgp Description: PGP signature
Re: Improve support for installing 32-bit libraries on 64-bit systems
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
Re: Improve support for installing 32-bit libraries on 64-bit systems
On Thu, Jun 24, 2010 at 10:38 AM, Michael Tsang mikl...@gmail.com wrote: I have a recommendation for 32-bit libraries on 64-bit systems: Multi-arch would be a better way to go: http://wiki.debian.org/multiarch http://www.lackof.org/taggart/hacking/multiarch/ -- bye, pabs http://wiki.debian.org/PaulWise -- 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/aanlktilm5e1jyjyh_yp2gsl7bvbrqycdk_1ajet5g...@mail.gmail.com
