[xemacs21*.deb] [FHS] Which is the real xemacs/site-lisp{,-21}?

[ Re: xemacs21*_21.1.*.deb packages by James LewisMoss <dres(a)debian.org&gt; ] I notice there are both "/usr/{lib,share}/xemacs/site-lisp{,-21}" directories installed[1]. Which one are folks who've installed the package supposed to use? I'd say the one in share... Which one does the XEmacs-21.1.8 debian package expect? Below, I propose a better, IMO, `load-path'. Answering my own question, I see that `load-path' is: [ abridged ] ("/usr/share/xemacs21/site-lisp/windows" "/usr/share/xemacs21/site-lisp/tdtd" "/usr/share/xemacs21/site-lisp/psgml" "/usr/local/lib/xemacs/site-lisp" "/usr/share/xemacs/site-lisp-21/" "/usr/share/xemacs/site-lisp/" "/usr/share/xemacs21/site-lisp/" "/usr/share/xemacs21/site-lisp/dpkg-dev/" "/usr/share/xemacs21/site-lisp/.../" [...] "/usr/share/xemacs21/site-lisp/windows/" "/usr/share/emacs/site-lisp" "/home/karlheg/.xemacs/lisp/" "/home/karlheg/.xemacs/xemacs-packages/lisp/" "/home/karlheg/.xemacs/xemacs-packages/lisp/karlheg/" "/usr/lib/xemacs/site-lisp/" "/usr/share/xemacs21/packages/lisp/" "/usr/share/xemacs21/packages/lisp/Sun/" "/usr/share/xemacs21/packages/lisp/.../" [...] "/usr/share/xemacs21/packages/lisp/zenirc/" "/usr/share/xemacs21/site-packages/lisp/" "/usr/lib/xemacs-21.1.8/lisp/" "/usr/lib/xemacs-21.1.8/lisp/mule/" "/usr/lib/xemacs-21.1.8/lisp/term/") Hmmm... some end in "/", others don't. I bet it doesn't matter... as long as any codes that use the elements of `load-path' call `file-name-as-directory' on them to canonicalize. Many of these have been pushed on the `load-path' by the "/etc/{x,}emacs/{*,}/site-start.d" codes. The main idea is that lisp codes meant for the more specific `emacs-version', ${configuration} and/or ${hostname} are car-end `load-path', and the more portable/general codes cdr-end, so you can drop in a repaired version of something that doesn't work without a patch, doesn't work in $EMACS <= $VERSION, should be available only on a certain architecture or host, or shadow them with enhanced versions; whatever you require or prefer. The lisp codes' installation location is up to the .deb package that installs the lisp codes (or shared-object plugin, on `module-path', iirc, l8r w/21.2). Put the `packages' lisp ahead of `site-lisp', since that's often XEmacs-patched (and "site-lisp" is considered deprecated now for XEmacs >= 21.1, right?) and put the "~/.xemacs/*" [2] stuff ahead of everything else so a user can override anything on the system at will. I think that the mule specific codes ought shadow the other codes, along the way down `load-path'. (see the order I have them in below.) We use "/usr/{local/,}/share" in preference to "/usr/{local/,}/lib" for reasons outlined in the Linux Filesystem Heirarchy Standard (FHS). (Think NFS/SAMBA shares.) Maybe we need a load-path sorter function to be called after all of the "/etc/{xemacs{/21{.1,},},emacs}.d files" [3] are run? Or a `deb-load-path-insert'? What do yous think? It might be faster and most convenient to sort them once at the end, with "/etc/xemacs/${SHORT_VERSION}/\ site-start.d/99pathsort.el". Note that with XEmacs >= 21.1, the "auto-autoloads.el" mechanism mostly obviates the need for the "/etc/xemacs/*/site-start.d" files. Those files could (maybe --- I've not tested it.) simply contain `custom-file' settings, if all they do is initialize variables.... Comments or ideas on this? (Themes will be way cool. ;-) What I think I'd try and make it look along, in order, for `load-path', follows. This will likely have to be done via the debian specific "site-start.el" (which runs everything in "/etc/{x,}emacs/*/site-start.d" in a specific order) mechanism, and not via the standard `load-path' initialization setup by "{startup,paths}.el".[4] We'd override the upstream `load-path' setup codes, and roll our own FOR NOW. The paths passed to `configure' will just be seed values, to make `xemacs -vanilla' work as expected. The XEmacs startup code path needs to be followed, brain-run and maybe worked on some, IMO... (my custom settings for `default-x-frame-plist' don't take effect until I create the second frame. Very annoying. It's a ToDo.) Anyway, here's my idea of what `load-path' maybe should contain, in order. ;; User can shadow anything. ~/.xemacs{/21{.1,},}/{{mule-,}packages/,}lisp{/karlheg,}/ ; [5] ~/.gnulisp/ ; ? Is this commonly used out there? I saw it someplace... ;; /usr/local/share is first, so the sysadmin can shadow ;; anything, or drop in site or host local codes. /usr/local/lib/xemacs{/21{.1.${xemacs-beta-version},.1,}}{/${configuration},}/{mule-,}packages/{${hostname}-,}lisp/ /usr/local/share/xemacs{/21{.1,}}/{mule-,}packages/{${hostname}-,}lisp/ /usr/local/share/xemacs/{21{.1,}/,}site-lisp/ ; deprecated ? /usr/local/share/emacs/site-lisp/ ;; Debian packages install lisp codes under /usr/share. /usr/lib/xemacs{/21{.1.${xemacs-beta-version},.1,}}{/${configuration},}/{mule-,}packages/lisp/ /usr/share/xemacs{/21{.1,}}/{mule-,}packages/lisp/ /usr/share/xemacs/{21{.1,}/,}site-lisp/ /usr/share/xemacs/21.1/lisp{/mule,,/term}/ /usr/share/emacs/site-lisp/ Trying to figure out where to put something would be less confusing this way... A README belongs in "/usr/{local/,}share/xemacs", as well as in "/usr/share/doc/xemacs*". I guess the ones in the lisp directories ought to be symlinks to the one in doc. There should be no non-architecture-dependant codes under "/usr/lib/xemacs/*" at all. I would not even ship the dumped .elc files; but would ship their .el files in the supportel or whatever. You'll need the source package to custom-redump anyhow. Perhaps much of the "etc/" directory could be left behind in the source package as well, maybe with a "replacement" README in there explaining where to find them. It's way easy to run `apt-get source' now. There will probably need to be a debconf-displayed warning message or (bluck, just don't hang and wait for me to press a key) preinst message iff there are files in the (deprecated) site-lisp directories? Hmmm. We need to think that over some. `install-emacs' will need an update for all of this to work, methinks. Any comments or ideas? Please discuss it with everyone on debian-emacsen! You are invited to subscribe at debian-emacsen-request(a)lists.debian.org. (smartlist). It's been, so far, a very low-traffic list. Karl M. Hegbloom <karlheg(a)debian.org&gt; <karlheg(a)inetarena.com&gt; [ By the way, I'm still hacking on my build and packaging setup for XEmacs, working with XEmacs-21.2-beta. These days, I'm learning all I can about CVS (`bitkeeper' sounds cool too... haven't tried it yet.) Maybe someday soonish (3 months, minimum) I'll finish it and upload it to experimental, ifwhen.please() I have permission from the xemacs-beta team && it actually builds and runs, else, I'll try and see about releasing to unstable with XEmacs-21.2. I remember the "flame-war" last summer, and will think up a good way to make things work nicely both for folks who want to use "~/.emacs" and those who prefer "~/.xemacs/init.el" or somesuch. Hey, if you want your GNU Emacs to bomb on XEmacs specific `customize' options, go for it. It's your life. In the source package, I will make it possible to easily define customized configurations and dumped-lisp sets, something like `make-kpackage' for XEmacs. ] Footnotes: [1] Listed in the xemacs21-basesupport.list files. [2] Another debate was whether it ought to be "~/.xemacs" or "~/xemacs". [3] In that order too, I think. [4] Note the literal `~', not expanded to the builders home directory. <grin> Don't you hate those kind of silly errors? It's 2am, and ten minutes after the release upload, and I just realized that... [5] This belongs in /etc/skel, with a README under it explaining things, along with a Makefile that recreates "auto-autoloads.el{,c}" and "custom-load.el{,c}" in there. **There needs to be a mechanism where when a package drops new or modified conffiles into "/etc/skel", it will notify all users of the new files, so they can `cp' or `ediff'.