This is sort of long. Don't bother unless you care about what /usr's contents look like, and/or you're desperate for reading material...
I've alluded in the past to my intention to package for Debian the cross development tools we're using for AMD 29200 embedded systems development. I care about this stuff because I'm working on an experimental payload module for the AMSAT Phase-3D amateur satellite project. I am motivated, in part, to do Debian packaging because most of the rest of my team is running one or another version of Linux, and most are willing to switch to Debian if I do this and it gets easier for them to track my tools work and stay up to date. Historically, I've always built the gcc/binutils/gdb/<etc> pieces with a '--prefix' of something like /usr/gnu or more recently /usr/cross, so that the whole cross-development "mess" ends up in a tidy subtree. This, in part, was because it was easy to clip the tree and hand it to someone else to install... partly becuase there used to be naming conflicts before the Cygnus and FSF folk got the cross-development prefixes working well... and partly because it just seemed "messy" to interleave the pieces into the rest of the filesystem. Besides, my cross-development tree is bigger than /usr/X11R6, even with both the XFree86 *and* X-Inside servers loaded! On the other hand, I'm trying to be a "good" Debian developer, and follow the FSSTND. But, I hit the same "ugliness snag" that the /usr/i486-linuxaout (sp?) discussion hits... I can either push the whole tree under something like /usr/cross, or I can prefix to /usr and end up with a set of directories with names like "/usr/a29k-amd-coff", "/usr/a29k-amd-udi", "/usr/go32", and so on. This is because of the way the GNU tools form target-specific directores when building cross-compilation tools. For reference, here's what it looks like with two AMD 29k targets built with a prefix of /usr/cross: [EMAIL PROTECTED]:~: du /usr/cross 7035 /usr/cross/a29k-amd-coff/bin 6 /usr/cross/a29k-amd-coff/lib/ldscripts 1849 /usr/cross/a29k-amd-coff/lib 11 /usr/cross/a29k-amd-coff/include/machine 36 /usr/cross/a29k-amd-coff/include/sys 119 /usr/cross/a29k-amd-coff/include 9004 /usr/cross/a29k-amd-coff 57 /usr/cross/lib/gcc-lib/a29k-amd-coff/2.7.0/include/objc 127 /usr/cross/lib/gcc-lib/a29k-amd-coff/2.7.0/include 12900 /usr/cross/lib/gcc-lib/a29k-amd-coff/2.7.0 12901 /usr/cross/lib/gcc-lib/a29k-amd-coff 57 /usr/cross/lib/gcc-lib/a29k-amd-udi/2.7.0/include/objc 127 /usr/cross/lib/gcc-lib/a29k-amd-udi/2.7.0/include 4411 /usr/cross/lib/gcc-lib/a29k-amd-udi/2.7.0 4412 /usr/cross/lib/gcc-lib/a29k-amd-udi 17314 /usr/cross/lib/gcc-lib 18593 /usr/cross/lib 104 /usr/cross/include 16420 /usr/cross/bin 404 /usr/cross/man/man1 405 /usr/cross/man 2443 /usr/cross/info 377 /usr/cross/a29k-amd-udi/bin 6 /usr/cross/a29k-amd-udi/lib/ldscripts 1844 /usr/cross/a29k-amd-udi/lib 11 /usr/cross/a29k-amd-udi/include/machine 225 /usr/cross/a29k-amd-udi/include/sys 308 /usr/cross/a29k-amd-udi/include 2530 /usr/cross/a29k-amd-udi 49500 /usr/cross [EMAIL PROTECTED]:~: So, is this better or worse than if the above had the '/cross' token taken out, and I set the prefix to '/usr'? There are no longer any naming conflicts. The current contents of the /usr/cross/bin directory, which would end up in /usr/bin if I use a /usr prefix, are (other cross targets would create similar sets of files/links): [EMAIL PROTECTED]:~: ls /usr/cross/bin a29k-amd-coff-ar* a29k-amd-coff-objdump* a29k-amd-udi-ld* a29k-amd-coff-as* a29k-amd-coff-ranlib* a29k-amd-udi-nm* a29k-amd-coff-c++* a29k-amd-coff-size* a29k-amd-udi-objcopy* a29k-amd-coff-c++filt* a29k-amd-coff-strings* a29k-amd-udi-objdump* a29k-amd-coff-g++* a29k-amd-coff-strip* a29k-amd-udi-ranlib* a29k-amd-coff-gasp* a29k-amd-udi-ar* a29k-amd-udi-size* a29k-amd-coff-gcc* a29k-amd-udi-as* a29k-amd-udi-strings* a29k-amd-coff-ld* a29k-amd-udi-c++filt* a29k-amd-udi-strip* a29k-amd-coff-nm* a29k-amd-udi-gasp* protoize* a29k-amd-coff-objcopy* a29k-amd-udi-gcc* unprotoize* [EMAIL PROTECTED]:~: What I'm currently contemplating is one source package (all targets are built in different object trees from one source tree), and a separate binary package for each target. The uncompressed size of each binary package is going to be on the order of 25-30meg, the uncompressed size of the source tree is about 50meg. I hope that doesn't cause anyone to panic... Someone interested in other targets could grab just the source package, and follow the "Notebook" file instructions I keep there to built a cross-gcc environment for any supported target... the hard part (getting all the FSF and Cygnus newlib pieces in one place, and forming the unified source tree) would already be done. Bruce also mentioned the notion that a 'cross-devel' subdirectory might want or need to be added to the distribution tree for Debian to handle these and other cross-development tools. I'm not opinionated about this at all, but I'd like to know what "the right answer" is. Comments, inputs, flames? I'm new enough to living on Linux that my opinions aren't cast in stone yet. But I don't want to have to do this twice, so knowing what "the troika" think the right answer is would help... If this isn't something that can/should be part of the mainstream distribution, say so too, because I suppose I could always privately publish the .deb's and achieve the effect we want for our project... Bdale