dv> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: dv> Sure. Actually, I'm surprised that GNU Emacs has this layout. What we dv> do here is having /usr/local/bin and /usr/local/lib[exec] shared by all dv> identical machines. emacs-20.3 would then install in /usr/local/bin and dv> /usr/local/libexec/emacs/20.3/ <that's all> and you're done for all these dv> machines. If you want to compile it for other architectures, you just do it on dv> another machine, or cross-compile and install through the /net filesystem. dv> You see that I don't have to add any mountpoints or whatever. All dv> directories needed to be shared are already there. But now you're making the assumption that machines of different architectures see different contents in the same directory (or rather, a different directory of the same name). This suggests consistency where there is none. (At least the system can't enforce or even check it.) Moreover, with filesystems more modern than NFS, you typically don't even have that choice, because the filesystems guarantees (or can at least check) that different contents => different directory name. There's a difference between not seeing something not intended for you and seeing something else in its place. Note also that now uninstalling a package is a real bitch since there potentially isn't even a machine that sees all the bits of it, at least definitely not in the obvious places. Furthermore (getting to the package system question), the solution to use with this layout is to have one package hierarchy under share/ (or whatever), and one under libexec/, conditionalized on architecture. If you want sharing of architecture-independent portions of fundamentally architecture-dependent packages (as I argued, an unlikely and at least rare situation), well that's where links come in. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla