On Thu, 10 Aug 2006 12:26:10 -0500 Mike Doty wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Donnie Berkholz wrote: > > Olivier Crete wrote: > >> It was chosen by brad_mssw to match the way it is done on ia64. > >> And I think we should continue to put the binary > >> app-emulation/emul-linux-x86-* in /emul/ and that lib32 should be > >> reserved for properly installed packages using portage whenever we > >> manage to get portage to support it. > > > > It makes sense that you wouldn't want these binary packages going > > into /lib32 or /usr/lib32, but /emul seems like an odd choice > > compared to something like /opt/lib32. I though exactly this when I saw SpanKY's query. Having a directory in '/' is not pretty. > IIRC, /emul predates FHS acceptance. also, while they are "binary" > packages, they arn't in the same catagory as binary-only packages. We > distribute them to assist multilib and to overcome problems that > portage wasn't really designed for. More generally we have varying approaches to pre-built packages; app-office/openoffice-bin installs to /usr for example, while mail-client/mozilla-thunderbird-bin and www-client/mozilla-firefox-bin install to /opt. In these cases, where they are installed on the same target architecture as they were built, I think it makes sense to have them install as if they were built with 'emerge -B' for installation via 'emerge -K' - i.e. in /usr rather than /opt. x86-built binary packages for x86_64 are not the same, of course. One idea that springs to mind immediately is to put them in a {bin,include,lib...} hierarchy under /usr/ (which is also where the compiler stuff for ends up). Conceptually at least (although no doubt problematic in practice) on x86_64 one could use a x86(_32) cross-compiler to build stuff to ROOT=/usr/${CTARGET}. Again in concept a /${CTARGET}/{bin,include,lib...} would exists for essential boot stuff, althought that's a bit academic. Just a thought for the pot ;) -- Kevin F. Quinn