sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: Hmm, these are not really arguments, are they ? You mean each package directory would have a ${arch}/lib-src subdir ? Well, we're talking about two different things here: first separating architecture-dependant stuff, and secondly /sharing/ what can be shared. If you distinguish architectures with different subdirs, that's all right, but that doesn't mean that you will actually share the lisp code, the etc stuff etc. This matter is also very important to me. I've got most of the packages installed and it's more than 22 Mo lisp code. Here, we have a /usr/local/share[1] directory which is automounted from a single machine onto the others. It's really comfortable to install stuff under it, knowing that all machines will immediately see it. From a sysadmin point of view, installing architecture independant stuff for XEmacs packages under this directory would be straightforward. However, imagine the pain it would be to update all machines on a site to make them mount /whatever/xemacs-packages/foo-1.32/lisp each time such a package is installed. If you're really against the split, I'd like to hear real arguments: how does it break the rationale, and why is it so bad to break it this way ? On the other hand, we could maybe reach an agreement on an intermediate solution, like having only one replication of the whole hierarchy. For instance: - put the original hierarchy under /usr/local/share/ organized in the way you described, with lisp, etc, info, man subdirs, but *not* lib-src, - put a clone of this organization under /usr/local/lib with lib-src stuff and possibly C modules Footnotes: [1] Reminder: Stallmacs installs its lisp code there. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19