Moin Ralf, dear list, On 4281 September 1993, Ralf Angeli wrote: > following up on a discussion from the xemacs-beta mailing list I'd > like to point out some issues with the XEmacs package Debian is > providing and suggest possible remedies.
First of all, I should mention that I'm unaware of any discussion on xemacs-beta, so I might not fully understand all issues. If so, please elaborate. > 1) /usr/local/share/emacs/site-lisp in load-path (bug #309747) > The load-path of Debian's XEmacs includes the directory > /usr/local/share/emacs/site-lisp. This directory is traditionally > used for the manual site-wide installation of GNU Emacs add-ons. > Basically the same is true for /usr/share/emacs/site-lisp. That means > one could question the decision adding this directory to load-path as > well. > Both directories are mentioned in Debian's Emacs policy document as > being a minimum requirement for all Emacsen. While one could argue > that /usr/share/emacs/site-lisp is under the control of the package > system which will assure that no files incompatible with XEmacs are > put into this directory, this is not the case for > /usr/local/share/emacs/site-lisp. One cannot rely upon local site > administrators adhering to the Debian scheme. I don't consider this a problem, quite to the contrary. The observed behaviour is in my understanding a feature. The directory /usr/local/share/emacs/site-lisp has been traditionally been used as a *common* directory in which to put files that are *intended* to be shared by users. I happen to use it for about eleven years now and it has always contained common startup-files as well as source code that is not distributed with either Emacs. Incompatibility concerns compiled Emacs Lisp files mainly and there are solutions to these concerns (one: use xemacs/ and fsfmacs/ subdirectories of site-lisp/ for the *elc-files, two: don't compile). Please also note that the problem is not really a XEmacs concern, but a version issue in general: there have been incompatibilities in compiled Elisp files between Emacs numbers (IIRC, 19 elcs vs. 20 elcs), and AFAIK, that's the reason for the version-numbered subdirectories under /usr/share/emacs/. > Taking AUCTeX as an example this means that a manual installation of > it for GNU Emacs will be put a tex-site.el into > /usr/local/share/emacs/site-lisp. Come on, this is really a ridiculous example. Debian ships (at least the last time I looked) an AUCTeX package that will not polute any directory intended for the /local/ additions of site-administrators. A much better example could have been a local installation of e.g. SLIME. However, during installation I didn't encounter any problems with XEmacs 21.5 and Emacs 21.3. Oops. > The file will try to add the content of the auctex subdirectory, > i.e. both source Elisp files and files compiled for GNU Emacs to > load-path. Because /usr/local/share/emacs/site-lisp is in XEmacs' > load-path it will pick up the AUCTeX installation intended for GNU > Emacs. Sure. If you happen not to know how to use a rifle, it's quite likely you'll shoot yourself in the foot, and Emacs and XEmacs are two hells of a machine gun. I have maintained multiple Emacs environments for several years and there are really known ways to handle the problem. Actually, Debian itself ships such a known way to install it's Elisp packages. > Anyway, XEmacs still picks up at least one wrong file. So taking > aside /usr/share/emacs/site-lisp because it is under the package > system's control, I think at least /usr/local/share/emacs/site-lisp > should not be added to XEmacs' load-path in order to prevent these > problems. I wholeheartedly disaggree. This results in duplicate local start-up code and duplicate source code storage etc., which is btw. one of the major drawbacks of the XEmacs package system, too (maintaining common versions of major packages between different Emacs incarnations *is* a concern, which is silently ignored by the XEmacs package system). Holger -- --- http://www.coling.uni-freiburg.de/~schauer/ --- Fachbegriffe der Informatik - Einfach erklärt 20: Multimediaentwickler Grafiker (Kristian Köhntopp)
