[xemacs21*.deb] [FHS] Which is the real xemacs/site-lisp{,-21}?
[ Re: xemacs21*_21.1.*.deb packages by James LewisMoss <dres@debian.org> ]
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@lists.debian.org. (smartlist). It's been, so
far, a very low-traffic list.
Karl M. Hegbloom <karlheg@debian.org>
<karlheg@inetarena.com>
[ 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'.
Reply to: