From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,eeee56c19a542f8d X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!postnews.google.com!i39g2000cwa.googlegroups.com!not-for-mail From: gshapovalov@gmail.com Newsgroups: comp.lang.ada Subject: Re: Multi-arch Date: 18 May 2006 09:34:34 -0700 Organization: http://groups.google.com Message-ID: <1147970074.739192.32410@i39g2000cwa.googlegroups.com> References: <1147857777.703653.268610@j33g2000cwa.googlegroups.com> <1147897909.555389.11030@38g2000cwa.googlegroups.com> <1147952398.152997.147430@j55g2000cwa.googlegroups.com> NNTP-Posting-Host: 85.218.19.247 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1147970080 12497 127.0.0.1 (18 May 2006 16:34:40 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 18 May 2006 16:34:40 +0000 (UTC) User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; appLanguage) AppleWebKit/125.5.5 (KHTML, like Gecko) Safari/125.11,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: i39g2000cwa.googlegroups.com; posting-host=85.218.19.247; posting-account=JLj9sw0AAAAfN2BnIEmryYsYbxhqZ35_ Xref: g2news2.google.com comp.lang.ada:4298 Date: 2006-05-18T09:34:34-07:00 List-Id: Ludovic Brenta wrote: > only guess, but it seems to me that the current infrastructure means > that each source package builds several binary packages, one for each > arch, on the machine where you build. So, for example, if you have an > amd64 machine, you'd get two binaries, i386 and amd64. Furthermore, the That sums up the principle pretty well. Of course there is also a lot of glue code to hold it all together and make it "just work".. > i386 package would install libraries in /usr/lib32, whereas the same > package built on a i386 machine would install libraries in /usr/lib, so > the two packages would be slightly different, and incompatible, even > though built for the same architecture. Debian is currently in a Yes, that would have made them (incompatible) if we were distributing binary packages. As it is, everything is built locally against installed libs. So this is not an issue in our case. > In the proposal, a source package would only produce one binary package > for the machine doing the build; thus your amd64 box would only produce > the amd64 binary. Then, if you want to install the i386 binary as well, > you'd take the package built by the i386 autobuilder, modify it on the > fly (this is one of the proposed changes to dpkg), and install it > alongside your amd64 package. This is actually quite similar to what is happening in Gentoo, as it does not make sense to make two versions of *every* package. Only the principal libs (parts of glibc and gcc rts) plus compatibility libs (of these actually only the ones that are dependencies of requested packages) are produced "by default". Then user is free to mix and match in a usual fashion, although most people just stick with defaults of course :). [skipping this part, as you rightly point out, most of these issues do not apply in our case] > - Gentoo users seem to like system administration :) > - Gentoo package maintainers seem to like difficult problems :) :). Although many people claim that their system administration efforts were reduced after switching to Gentoo :). Well, as usual, this is an issue of how you think and what tools you like I guess.. > The proposal also hints at the LSB. I think it would be necessary to > standardise the library paths across all distros. The current /usr/lib, > /usr/lib32, and /usr/lib64 directories are not general enough. Consider > that some HP processors can run i386, amd64, ia64, hppa *and* hppa64 > binaries on the same machine :) And what about Cell processors and > other future asymmetric multiprocessors? What about binaries intended > to run on GPUs or other coprocessors? Definitely, this will have to be done. Unfortunately I do not see it happening *just yet* - having seen how much it takes to organize anything on a large scale :). However in 2-3 years and when we can persuade LSB people that Linux/BSD/FOSS is not limited to Red Hat.. (admittedly they are getting better at that lately). But we can start by having a discussion among Gentoo and Debian toolchain people (or what gcc/glibc "subproject" is called in Debian?) George PS Does anybody know of a public newsserver that would allow to post? I would really like to do all my email/messaging from one place (a trusty kontact :)), rather than having to browse to google groups just to post the reply..