dv> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: dv> [...] You'd understood that it doesn't fit mine. Ah! No, I hadn't. Please explain why. dv> That's disapointing as well as worrying to hear that. It sounds like dv> you're closed to any discussion on this just because it is a problem (or a dv> feature) you just don't want to care about. I don't even see your problem yet. I think it's wrong to intermingle the design issues concerning the package layout with the global issues of XEmacs directory layout. If you make one depend on the other, it's much harder to make local changes. I want to be working on the package system, not the global directory layout. For the directory layout issues, I don't stand a chance against you, and I don't want to. Moreover (and please acknowledge this, Didier), there are software setups *other* than yours (notably, ours) where hard-wiring what you're suggesting is going to royally fuck things up. At the file system level, a package constitutes a collection of files that belong together. With hierarchical file systems, the *only* way to reflect "togetherness" (as well as "apartness" from other packages, say) is to put those files into a common subdirectory which is not a subdirectory containing other packages. This has a number of advantages, two being ease of installation and un-installation as well as an easy-to-satisfy integrity criterion. The latter point is especially important since I can check package integrity *locally*, and it's pretty hard to violate it without seeing what you're doing. Once the package is spread out as you suggest, installation is still easy enough, but suddenly, if I want to uninstall or move or ship a package, I have to remember where all its bits are. If I forget some of them, there's no guarantee the system will *ever* notice that fact. dv> Again, I'm sorry, but no way. This is like doing consciously something dv> wrong first, and then reparing the damage afterwards. I'm not ready to make dv> dozens of symlinks even if it's automatized in any fashion. Well, so there. I'm not ready to spread packages over disparate portions of the hierarchy. Seriously, links *are* Unix's native mechanism for expressing sharing. You may not like it, but it's the only thing there is. They're not exactly a neat design, but they're excruciatingly easy to manage automatically. Yet another solution for achieving maximum sharing without links is to factor the architecture-specific portions of a larger packages into packages of their own. This makes sense for staging reasons as well. Stick the architecture-independent bit into a shared package hierarchy, and the architecture-specific bit into one conditionalized on architecture. dv> But please, don't say things like "I won't change it". I never said that. How come you claim this? -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla