dv> Well, we're talking about two different things here: first dv> separating architecture-dependant stuff, and secondly dv> /sharing/ what can be shared. Michael> Sure, but that's mostly a high-level organizational Michael> issue, and different systems address the issue in Michael> different ways. You cater to one, you hurt the others. dv> Here, we have a /usr/local/share[1] directory which is dv> automounted from a single machine onto the others. It's really dv> comfortable to install stuff under it, knowing that all dv> machines will immediately see it. From a sysadmin point of dv> view, installing architecture independant stuff for XEmacs dv> packages under this directory would be dv> straightforward. However, imagine the pain it would be to dv> update all machines on a site to make them mount dv> /whatever/xemacs-packages/foo-1.32/lisp each time such a dv> package is installed. Michael> I'm afraid I don't understand the point you're making. Michael> If a package contains architecture-depdendent stuff, you Michael> obviously need to install at least parts of it somewhere Michael> other than /usr/local/share if you want to preserve the Michael> integrity of your setup. I don't know if that means Michael> requiring explicit mounts, but that doesn't really Michael> matter. Why not install the whole thing somewhere else Michael> then? If you want sharing in your setup, that's what Michael> symbolic links are for. They are trivially managed by a Michael> set of two shell scripts. I think it would work best to make each of the directories a configurable option, so that the site admin or package builder can decide where to install stuff. Isn't that how things are normally done anyhow? I'd put the cross architecture shareables under .../share/..., and the binary modules under .../lib/..., perhaps by using --switches to `configure' if that exists, (with a default that follows the LHS or GNU Coding Standards filesystem layout would be best). That's what Didier is talking about, I think. Here there's /usr/share/emacs/{20.{2,3},site-lisp}/, and /usr/lib/emacs/20.3/i386-debian-linux-gnu/ from the Emacs 20 (i386) Debian package. I suppose that on a server, there could be subdirs there in lib for other architectures, and that you'd have .../arch-bin directories that get mounted on the client hosts as just .../bin. So I think there needs to be a configurable way of installing. Perhaps as root, an XEmacs site admin could run the package installer thing, after having configured site directories using `customize' widgetry, have it fetch the tarfile for per architecture, and it would unpack it someplace temporary, then move the subdirs inside it into the set locations. To make a debian package of something, I build a sub-filesystem (rooted at "$(pwd)/debian", pretending to be "/") and move the stuff into it, as if ready to form a .tar, then let the packaging tools pack that up. When somebody installs it, everything will go where it belongs, since the tarfile inside the .deb will essentially be opened from "/". What about stuff that assumes something resides in a certain location? Usually that's solved by using --prefix, --libdir, --statedir, etc. with `configure', then installing to the pseudo-root with `make PREFIX=$(pwd)/debian/tmp ... install'. This way the insides have the actually after-actual-installation paths, but the install target puts things into your staging directory. (as designed.) I hope this proves I've learned something.