dv> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: dv> [...] You'd understood that it doesn't fit mine. dv> Because, as I've already explained, I already have network-ally shared dv> standard directories, that your design won't use and it's a shame because I dv> would have to make the concerned packages directories sharable by hand (or dv> script) each time a new package appears. That's not the case. You need (well, "may want" is probably a better term) to do this only when a package appears which has both an architecture-dependent portion and a sizeable architecture-independent portion. I believe the number of these so far is <5, a small percentage of the existing packages anyway. *You* don't necessarily need to do anything in that case, the package installer can take care of that transparently. Moreover, if we organize the packages right (namely by making packages fit tightly around their architecture-dependent portion, which makes sense in other ways as well), you kan keep the number of these packages close to zero. dv> Please explain precisely why and how. In a Unix software installation, you have several keys upon which to index them, among them: - architecture - package - package component (documentation, binaries, etc.) - version - availability ... Given a hierarchical file system, you need to assign these to depths in your installation hierarchy. This means that there's an ordering of these criteria. However, this ordering is not a natural property of these keys---you'd rather want a database where each of these have equal precedence. The GNU standards impose one such ordering by having (I may be wrong since we don't use it) a share/ hierarchy and a lib/ or libexec/ hierarchy, deep underneath which lie the architecture-dependent portions. At least emacs-20.3 has, by default, the following architecture-specific portions in its hierarchy: bin/ libexec/emacs/20.3/<architecture> This means that the architecture-specific parts of Emacs are spread over two different hierarchies. It would make plenty of sense, however, to mount the architecture-specific portions of a software package only on the machines of that particular architecture. (In fact, at least he popular AMD automounter has native support for that kind of thing.) The GNU standards make that next to impossible, requiring at least one additional mountpoint per package. We happen to have an installation where architecture is the primary key (i.e. it's at depth 0 in the hierarchy). Needless to say, packages using the GNU standard do not cooperate too well with it. dv> You told me to use scripts to make my links, so I tell you to use dv> scripts to uninstall. Moreover, remembering to look in *two* places, like dv> share/ and lib/, is not that much to remember I think. There are more than two places: You get one additional place per architecture, if you do this right. dv> There are NFS, automount ... NFS is far from a "native mechanism" for Unix. It doesn't implement Unix filesystem semantics (or any semantics, for that matter), and automounting is far from standardized. It doesn't run on my Unix box, for instance. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla