Re: New package system design draft

dv> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: 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