An example Emacsen policy
While the unilateral chorus of Debian developers states that the
current state of the Debian policy is perfect and can't be improved at
all, I'd like to see the less perfect people upstream catered for.
So I'll outline a proposal of what I would think would entail a sane
Emacsen policy.
First a few observations:
a) XEmacs has a package system of its own. The stuff in that package
tree has a structure distinctly different from the stuff in Emacs Lisp
trees. For that reasons, it does not seem feasible to install common
Emacs packages into the package tree of XEmacs.
b) some stuff is provided in the XEmacs sumo tar ball. As a rule,
stuff in the sumo tar ball is older than what might be provided as a
common Emacs package.
c) the current "do it the Debian way or else" is not suitable for
letting people play around with developer versions, or let developers
play with Debian packages.
If Debian is not a completely different world from standard
compilations of Emacs/XEmacs, this will be helpful.
So what are things that I would want to have different?
a) .el files and corresponding .elc files need to be in the same
directory. This is the way paths and path searching and byte
compilation are organized in Emacs and XEmacs, and quite a bit of code
relies on it.
b) as an obvious corollary, any generic Elisp packages should unpack
into a place outside of all Emacs trees, and outside of any load-path.
The procedure that is now responsible for byte-compilation, will
become responsible for copying and/or linking the files. Hard links
might not work across file systems, soft links might not work when
exporting just a specific Emacs tree (though this might be manageable
with suitable export options). It would appear that the safest choice
would be to copy source files to their final location, closely
followed by the symbolic link solution.
c) the XEmacs package system requires packages to be in a rather
specific format, and with precompiled Lisp files. Generic Elisp
packages will not usually be in that format. For that reason, generic
Debian Elisp packages will not install into an XEmacs package tree.
d) an XEmacs-specific Debian package should shadow a generic epackage.
The search order for a Debian-installed XEmacs is probably the most
complicated one to be considering, other stuff is a subset of that.
So what would the usual search order be?
user-specific site-lisp
user-specific XEmacs packages (something like ~/.xemacs-packages)
site-specific site-lisp (something like /usr/local/share/xemacs21/site-lisp)
site-specific XEmacs packages (something like /usr/local/share/xemacs21/site-packages)
debian-packages for XEmacs package tree (/usr/share/xemacs21/site-packages)
debian-packages for generic Elisp trees (/usr/share/xemacs21/site-lisp)
debian-packages for complete sumo/etc tree (/usr/share/xemacs21/xemacs-packages)
Debian packages specifically for some XEmacs flavor would install
right into the /usr/share/xemacs-21/site-packages tree. The only
thing affected by update-emacsen will be the generic Elisp tree.
Actually, the "site-*" in /usr/share/xemacs21/site-* is not a
complete misnomer since it holds a site-specific choice of packages
added to (or overriding) the basic XEmacs tree. Still, it might be an
idea to name it dist-* or similar to avoid having the user tamper with
that tree.
The generic Elisp packages come in subtrees in /usr/share/emacsen that
are to be copied and installed right over to xemacs-21/site-lisp by
update-emacsen. So what kind of stuff would be in there?
/usr/share/emacsen/auctex/site-start.d/auctex.el (startup file for AUCTeX)
/usr/share/emacsen/auctex/auctex/* (Lisp files)
/usr/share/emacsen/auctex/info/auctex.info (info file)
/usr/share/emacsen/flavors/xemacs21/auctex symbolic link to
/usr/share/emacsen/auctex
/usr/share/emacsen/flavors/xemacs21/site-lisp symbolic link to
/usr/share/xemacs21/site-lisp
Ok, now assume that a user wants to compile and maintain his own
version of Emacs and does this, without any regard for Debian's
sophisticated system, by doing
./configure --with-prefix=/usr/local/emacs-unicode
make
make install
But the user is too lazy too maintain his own variant of AUCTeX,
instead preferring the Debian installation. So he does
mkdir /usr/share/emacsen/flavors/emacs-unicode
cd /usr/share/emacsen/flavors/emacs-unicode
ln -s /usr/local/emacs-unicode/share/emacs/site-lisp .
ln -s /usr/local/emacs-unicode/bin/emacs .
ln -s ../../auctex .
update-emacsen
That's it. From now on the Debian AUCTeX package is compiled and kept
updated also for his personal compilation. To have working
autostarts, the user will still have to put something like
(mapc #'load-file (directory-files
(expand-file-name "site-start.d" (file-name-directory load-file-name))
t ".el\\'"))
into his Emacs' site-start.el file. But that would probably be the
standard content of a normal site-start.el file from Debian and might
be copied from some template /usr/share/emacsen/site-start.el.
Ok, the details would require further working out, but the main idea
is to keep the Emacs installations very similar to their
out-of-the-box state (apart from the necessary search path additions
to provide both overriding-package paths as well as site-compiled-lisp
paths). Compiling new Emacs versions does not require thinking in
advance of how to integrate with Debian. You just place a few
symbolic links, and your stuff is integrated with the scheme.
And you can easily detach your own compilation from the scheme, or
attach it just to a few packages.
Some things would need to get out in more detail, but basically I
think that this sort of scheme would make it easy for people to play
around with the Debian scheme or let it be. Since the Emacs
compilations from Debian would merely feature a slightly augmented
search path and a predefined site-start.el, there would be very little
motivation for people to remove this and do their own compilation: the
main difference would just be that a set of symbolic links had already
been established. Those links would just be used for maintaining
compiled versions of Debian packages in the site-lisp tree. Removing
the directory with the links would remove Debian's control over the
installations in the site-lisp tree.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
Reply to: