Re: about the packages: directory names and places

dv> You can't force ~/.xemacs to be *THE* user-local package directory by dv> default because the user should be able to do what it wants in this dv> directory. I for instance have other subdirs like autosave/, drafts/ and dv> others, and I had a lisp/ dir for stuff not being in any package (code under dv> development, random hacks ...). I would then prefer to have a packages/ subdir dv> under ~/.xemacs/, and use it to install packages locally. IMPORTANT NOTE: XEmacs currently expects the user-specific package hierarchy in ~/.xemacs. This will probably change to ~/.xemacs/packages in a future version of XEmacs. dv> To stay coherent in the placement scheme, this also means that I'd dv> prefer to see a packages/ subdir, everywhere packages could be installed. In dv> other words, instead of having site-packages, mule-packages and dv> xemacs-packages under ${prefix}/lib/xemacs/, I'd prefer to see dv> ${prefix}/lib/xemacs/packages/ and then site/ mule/ and xemacs/[2]. But the rationale behind the current naming scheme is different: The directory names `xemacs-packages' and `mule-packages' correspond to features `xemacs' and `mule.' Steve had some further development of this in mind. This is also why this sort of naming "scheme" does not apply to ~/.xemacs/packages. dv> 2/ Importance: 3/5 dv> The name xemacs-packages is not informative for people: all packages dv> are for xemacs. This is only currently so. Ultimately, this is meant to be complemented by `infodock-packages', `emacs-packages' (or `fsf-packages' :-} ) and so on. dv> 3/ Importance: 4/5 dv> The presence of the mule subdir appears questionable to me: this dv> separation is put on the same level as the site-level or distrib-level split, dv> but it has nothing to do with it. Consider this: dv> - having site-packages is good, not only because you can put random dv> stuff not in the distribution, but because it will allow you to override any dv> packages already installed in the standard place (xemacs-packages) with dv> something newer, locally modified, of a different flavor or whatever. For mule dv> stuff this doesn't appear possible, since all mule stuff is supposed to go in dv> the mule-packages directory. dv> - if somebody writes a new package for mule, where does it go ? under dv> site-packages or under mule-packages ? This is ambiguous. This is a very good point. I'll think about this. dv> 4/ Importance: 5/5 dv> Currently, the default prefix is ${prefix}/lib/xemacs. There, I'm dv> gonna be very direct, sorry, but this is the *WRONG* place. Everything in dv> packages is architecture independant: Huh? The architecture-*dependent* stuff is under a subdirectory with the name of the architecture. Nothing in the name "lib/xemacs" suggests architecture-dependence. Of all the 150+ software packages I've installed, only 10 even *have* a `share' directory, but plenty have architecture-independent stuff in `lib.' Plus, you can change the locations of pretty much everything via configure. So, given the fact that there are no standards as to the directory structure of Unix software, I claim that this particular way of doing it is at least as good as any other. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla