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

[Alan Mackenzie <acm@muc.de>]

'Evening, Don!

On Mon, Jul 14, 2008 at 01:42:42PM -0700, Don Armstrong wrote:
> On Mon, 14 Jul 2008, David Kastrup wrote:
> > Alan Mackenzie <acm@muc.de> writes:
> > > It took me ~2 hours to get my Emacs to find my site-start.el -
> > > Debian (and thus Ubuntu too) puts a content-free site-start.el
> > > somewhere in /etc which blocks out your own real one.

> Just edit /etc/emacs/site-start.el if you want it emacs wide, or shove
> stuff into /etc/emacs<flavor>/site-start.d/; it's pretty trivial.
> [Though frankly, most things that people think they should shove into
> site-start.el doesn't belong there: it belongs in ~/.emacs.]

You know, there's something about that sort of reply which makes me want
to scream, possibly even want to strangle its writer;  it's the words
like "just" and "pretty trivial".  OF COURSE it's "pretty trivial", after
having wasted ~2 hours of my time tracking down the problem.  Those ~2
hours of my life are permanently lost, they're gone for ever, I'll never
get them back again.

I think I can confidently predict it has wasted similar amounts of time
for lots of other people, too.

What makes it not so bad is the belief that the Debian Emacs guy (is this
you, Don?) didn't create the existing setup with the intention of fouling
up expert Emacs users' setups, wasn't really intending to mess people
around unnecessarily.  However, if that had been his intention, surely he
would have done what he actually did, just with a dose of malice thrown
in.

> > 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. Thanks to that system,
> installing packaged emacs add-ons is absolutely trivial.

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/ (This is documented on page "Init File"
of the Emacs manual.)

> If you're lost, see
> http://www.debian.org/doc/packaging-manuals/debian-emacs-policy

Yes, that's all well and good.  Trouble is, when installing an operating
system like Debian, I'm not in the habit of grepping Debian's online
documentation for each package I'm installing, just on the off-chance
that the distro might have silently broken the package's normal
conventions.  That would markedly increase the time and tedium involved.

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.

I do not see the purpose of this extra layer of complexity that Debian
has wrapped around (X)Emacs.

> > 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.

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.

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?

> Don Armstrong

-- 
Alan Mackenzie (Nuremberg, Germany).