dv> other words, instead of having site-packages, mule-packages dv> and xemacs-packages under ${prefix}/lib/xemacs/, I'd prefer to dv> see ${prefix}/lib/xemacs/packages/ and then site/ mule/ and dv> xemacs/[2]. ms> But the rationale behind the current naming scheme is ms> different: The directory names `xemacs-packages' and ms> `mule-packages' correspond to features `xemacs' and `mule.' ms> Steve had some further development of this in mind. This is ms> also why this sort of naming "scheme" does not apply to ms> ~/.xemacs/packages. I don't see why Didier's scheme doesn't implement this rationale as well. And user-local packages should support the mule/non-mule differentiation, as long as it exists. On one large multi-user systems I know XEmacs is basically being supported by a user out of his ~/.xemacs. dv> something newer, locally modified, of a different flavor or dv> whatever. For mule stuff this doesn't appear possible, since dv> all mule stuff is supposed to go in the mule-packages dv> directory. - if somebody writes a new package for mule, where dv> does it go ? under site-packages or under mule-packages ? This dv> is ambiguous. ms> This is a very good point. I'll think about this. I think this is a strong argument in favor of Didier's scheme, because it permits a general mechanism of directories named for low-level features like 'xemacs and 'mule. And I don't think 'fsf will ever work the way 'xemacs does; could RMS ever agree to anything like that? So you would have to special-case that. But under Didier's scheme, packages that work in any Emacs regardless of the the presence or absence of non-require'able features like 'xemacs would be under the ${prefix}/lib/xemacs/packages/ directory, and it would work naturally. Given our practice of tracking GNU API changes where we don't have reason not to, I don't think this is too dangerous. dv> Currently, the default prefix is ${prefix}/lib/xemacs. There, dv> I'm gonna be very direct, sorry, but this is the *WRONG* dv> place. Everything in packages is architecture independant: ms> Huh? The architecture-*dependent* stuff is under a ms> subdirectory with the name of the architecture. Nothing in ms> the name "lib/xemacs" suggests architecture-dependence. This is a Linux-ism; the Linux FSSTND specifically encourages the placement of architecture-independent files under .../share/, and reserve .../lib/ for host-dependent (either for reason of architecture or host specificity) files. All the major Linux distributions now comply with this, Debian is pretty fanatic about it. I like the FSSTND approach well enough, and will do my own installations that way, at least for now. However, there are two reasons for not doing it this way by default: (a) as Michael pointed out, many, probably the majority, of existing hosts don't have .../share/; enforcing it will confuse their users and admins, and could be annoying if the local XEmacs maintainer doesn't have rights to the .../ directory (we do this here, we trust student maintainers with, eg, /usr/lib/httpd/cgi/..., but we don't give them write access to /usr/lib and certainly not to /usr). (b) there are alternatives, such as the depot system of Barry Warsaw et al., that allow architecture-dependent files to go into .../share/ or its equivalent. Neither of these is that strong a reason against putting the architecture independent stuff in .../share by default, and putting it there certainly will make Linux distribution maintainers happy. I don't know if GNU has adopted .../share as a standard, but I know that several GNU packages I have built locally use it (the Linux versions obviously aren't a fair test since they're explicitly made to be FSSTND compliant). -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +1 (298) 53-5091