>>>>> "dv" == Didier Verna <verna(a)inf.enst.fr> writes:
dv> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes:
>> Probably a workable approach is to distinguish architectures under <whatever
>> the name of the directory>, and let the high-level directory structure just
>> do what it needs to do.
dv> You mean each package directory would have a ${arch}/lib-src subdir ?
Actually, I was thinking of lib-src/${arch}, but that's not really
important.
dv> Well, we're talking about two different things here: first separating
dv> architecture-dependant stuff, and secondly /sharing/ what can be
dv> shared.
Sure, but that's mostly a high-level organizational issue, and
different systems address the issue in different ways. You cater to
one, you hurt the others.
dv> Here, we have a /usr/local/share[1] directory which is automounted
dv> from a single machine onto the others. It's really comfortable to install
dv> stuff under it, knowing that all machines will immediately see it. From a
dv> sysadmin point of view, installing architecture independant stuff for XEmacs
dv> packages under this directory would be straightforward. However, imagine the
dv> pain it would be to update all machines on a site to make them mount
dv> /whatever/xemacs-packages/foo-1.32/lisp each time such a package is installed.
I'm afraid I don't understand the point you're making. If a package
contains architecture-depdendent stuff, you obviously need to install
at least parts of it somewhere other than /usr/local/share if you want
to preserve the integrity of your setup. I don't know if that means
requiring explicit mounts, but that doesn't really matter. Why not
install the whole thing somewhere else then? If you want sharing in
your setup, that's what symbolic links are for. They are trivially
managed by a set of two shell scripts.
For every organizational scheme you name, I'll name you a different
one with exactly the reverse tradeoffs. The only way you can at least
try to cater to all of them is to avoid being dependent on the
tradeoffs.
dv> If you're really against the split, I'd like to hear real arguments:
dv> how does it break the rationale, and why is it so bad to break it this way ?
With one package, one directory you still have the *choice* whether to
replicate or not, and you can address the whole replication issue
independently. You spread out a package over several directories, you
don't have that choice anymore.
dv> On the other hand, we could maybe reach an agreement on an
dv> intermediate solution, like having only one replication of the whole
dv> hierarchy. For instance:
dv> - put the original hierarchy under /usr/local/share/
dv> organized in the way you described, with lisp, etc, info, man subdirs, but
dv> *not* lib-src,
dv> - put a clone of this organization under /usr/local/lib
dv> with lib-src stuff and possibly C modules
Again, I don't want to mess with the high-level directory
organization. I don't particularly care one way or another, and I'll
let someone else sort out that particular mess.
dv> Footnotes:
dv> [1] Reminder: Stallmacs installs its lisp code there.
Not out here it doesn't. You mean Stallmacs installs there *by
default*. So what?
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla
