SO. Here are some comments that I have (or haven't) done before about things that sound non optimal to me in the current packaging stuff. I'll try to be very clear and precise in my comments this time. Also I'll try to point out the things that I consider the most important ones. Obviously, all the stuff below is IMHO, not directed at anyone in particular and only aimed at debating ideas that I think could improve the current scheme. Currently, the default scheme is to install packages under ${prefix}/lib/xemacs, respectively in site-packages, xemacs-pakages and mule-packages. 1/ Importance: 2/5 I personally don't like this `-packages' name replication, but I think that there is more than a matter of personal taste: basically I think that first, you can't force ~/.xemacs to be a user-local package directory[1] and second, it's important that the naming scheme remains coherent across user-local, site-local and distribution-wide placements. You can't force ~/.xemacs to be *THE* user-local package directory by default because the user should be able to do what it wants in this directory. I for instance have other subdirs like autosave/, drafts/ and others, and I had a lisp/ dir for stuff not being in any package (code under development, random hacks ...). I would then prefer to have a packages/ subdir under ~/.xemacs/, and use it to install packages locally. To stay coherent in the placement scheme, this also means that I'd prefer to see a packages/ subdir, everywhere packages could be installed. In other words, instead of having site-packages, mule-packages and xemacs-packages under ${prefix}/lib/xemacs/, I'd prefer to see ${prefix}/lib/xemacs/packages/ and then site/ mule/ and xemacs/[2]. 2/ Importance: 3/5 The name xemacs-packages is not informative for people: all packages are for xemacs. The difference is that those ones are standardly distributed and can be grabbed from the XEmacs ftp site. Instead it would probaby be better to prefix it with standard-, distrib-, core- or something like that. (or if 1/ is agreed on, name it directly like this ;-)) 3/ Importance: 4/5 The presence of the mule subdir appears questionable to me: this separation is put on the same level as the site-level or distrib-level split, but it has nothing to do with it. Consider this: - having site-packages is good, not only because you can put random stuff not in the distribution, but because it will allow you to override any packages already installed in the standard place (xemacs-packages) with something newer, locally modified, of a different flavor or whatever. For mule stuff this doesn't appear possible, since all mule stuff is supposed to go in the mule-packages directory. - if somebody writes a new package for mule, where does it go ? under site-packages or under mule-packages ? This is ambiguous. This makes me think that instead of the current 3 parts split, we'd better have `mule' as a sub-split under both site-packages and xemacs-packages. Like having site-packages/, site-packages/mule and the same for xemacs-packages. This modification solves the two problems cited above, and makes tarball installation easier too: a mule package tarball could now be built with the mule/ prefix, and thus people could not make the mistake of installing a mule package under a non mule installation directory. 4/ Importance: 5/5 Currently, the default prefix is ${prefix}/lib/xemacs. There, I'm gonna be very direct, sorry, but this is the *WRONG* place. Everything in packages is architecture independant: info files, etc random stuff, lisp and bytecode. So all this stuff should go at least under ${prefix}/share/ and not lib. Many people mount /share by NFS on heterogeneous networks exactly because it is meant for arch-independant stuff. I have almost all of the packages installed and this represents about 50Mo. Preserving 50Mo sounds worth it to me, if by any chance you wouldn't be convinced that it's better to use share/ rather than lib/. All right. I think that's it. I'd like to hear comments from anybody, not only for those involved in the packaging code development. Now, I've turned up my power-shield. You can BGF9000ize my head[3]. Footnotes: [1] I didn't find any information on this lately, so I'm assuming that this is still the package directory for users. [2] see next point though. [3] "shoot shoot, don't talk." -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19