Debian's idiosyncratic complexification of Emacs [Was: Emacs vista build failures]

[Stephen J. Turnbull]

 > On Mon, Jul 14, 2008 at 01:42:42PM -0700, Don Armstrong wrote:
 > > David Kastrup wrote:

 > > > Forget about Debian and Emacs. They use a clever system for sharing
 > > > package code between different Emacs versions (which you can install
 > > > at the same time) and XEmacs, so clever that nobody understands it.
 > 
 > > Lots of us understand it; it's pretty trivial.

I beg to differ.  The Debian Emacs Policy was a major PIMA for a
couple of years.  It may be simple to state by now, but its evolution
was complex.  The current state of peaceful coexistence required a
number of tweaks.

 > > Thanks to that system, installing packaged emacs add-ons is
 > > absolutely trivial.

Well, there are several other systems that make installing packaged
Emacs add-ons absolutely trivial.  Of course Debian would have a
massive case of indigestion if you used them on a Debian-installed
Emacsen, so they're kinda preempted.  And historically, Debian
installed add-ons caused a lot of annoyance to both upstream
developers and users of Debianized Emacsen.

Alan Mackenzie writes:

 > Tell me, why is it considered helpful to include a content-free
 > site-start.el?  The only thing this does is to prevent the loading
 > of the site-start.el in the standard Emacs place, i.e.
 > /usr/local/share/emacs/site-lisp/

Don't you mean $prefix/share/emacs/site-lisp?  IMHO, Debian should
leave /usr/local pretty much entirely alone, maybe looking there
late-ish in load-path or something.  Site configs for Debian's Emacsen
shouldn't be in /usr/local, though.  For the Debian-distributed Emacs,
prefix=/usr, and /usr/share/ needs to be reserved to Debian.  OTOH,
user settings kept in /etc/emacs/ will be carefully preserved by
Debian tools.

At one time it wasn't content-free, either.  In particular, it loaded
the initialization code for packaged Lisp.  This meant that you could
do --no-site-file in XEmacs (what's Emacs's idiom?) and do a packaged-
Lisp-free bug report on core features.  This is especially important
if you've got monkey-patch libraries like APEL around.

The easy thing to do is simply let Debian install an Emacs-to-keep-
deb-deps-happy, and put your developer's Emacs (pl?) in /usr/local or
/opt.  Each Emacsen will then look in the standard place relative to
its own $prefix (modulo Debian's redefinition of "standard").

 > And even the maintainer of this document, debian-emacs-policy, admits
 > that it's not in an optimum state.  It's not clear what the purpose of
 > `debian-startup' is (Emacs works well without it), or to whom Emacs must
 > indicate its flavour (er, flavor ;-), and what that achieves.

Emacs v. XEmacs and Mule v. no-Mule introduce various bytecode
incompatibilities.  "Flavor" is used to point load-path at compiled
Lisp that works for each variant.  AFAIK that's explained in the Emacs
Policy document, but it's been a while since I read it.

The David and Don Show returns:

 > > > I know of _no_ upstream Emacs or XEmacs developer who claims to
 > > > understand or get along with the Debian setup.
 > 
 > > There's no need for upstream developers to bother, since it's all
 > > handled for them by Debian Developers.

Except for bug reports.  Debian's XEmacs (unlike, say, Mandrivel's) is
quite clean of core patches, so I don't recall ever needing to fire up
a Debian XEmacs to diagnose a bug.  (Of course, if it looks like a
load-path issue, I always try to bounce it back to Debian, since it's
their load-path, not ours.  But even there --debug-paths (does Emacs
have this switch?) usually wins if the user comes back to us.)

And back to Alan:

 > Sorry, Don, you're just wrong here.  It's _precisely_ the Debain
 > Developers' inclusion of the "blocking library"
 > (/etc/emacs<..>/site-start.el) which forces upstream developers
 > like me such bother.

In the spirit of the GPL, Debian probably should have a notice on the
splash screen that they've moved the standard startup files, and a
link to an info node describing them.  I'd not be surprised if it's
already there but you just didn't notice it.

 > Why is it necessary to include these content-free files?  Is there not
 > something that the Debian Emacs maintainer could do to resolve this
 > problem?  How about changing the order of the directories in load-path,
 > for example?

"See above", "not much", and "obviously they already do that,
presumably with malice[sic] aforethought".

N.B. I come not to praise the Debian Emacs Policy, but to give it its
due: it's a reasonable compromise for the vast majority of users of
Emacsen.