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

[Alan Mackenzie]

'Morning, Don!

On Mon, Jul 14, 2008 at 06:38:45PM -0700, Don Armstrong wrote:
> On Mon, 14 Jul 2008, Alan Mackenzie wrote:
> > Those ~2 hours of my life are permanently lost, they're gone for
> > ever, I'll never get them back again.

> Perhaps I'm being elitist, but it took me all of 5 minutes to look up
> the documentation for this, and rework through how this all was done.

Will you please get the point.  It isn't the time it takes to "look up
documentation", or the 35.72 seconds it takes to edit an elisp startup
file.  It's the two hours it takes from realising "something's not
working here", going through checking things like pertinent disk
partitions are mounted, there's no symbolic links fouling things up.
Maybe I'm hopelessly old-fashioned here, but when I see something not
working, I usually assume it's my fault, first.

If this sort of thing happened on every Debian package, and you install,
say, 100 packages at installation, this would add an extra 200 hours to
the installation process.

> And no, it's not me.

:-)

> >  Tell me, why is it considered helpful to include a content-free
> > site-start.el?

> We don't include a content-free site-start.el; here is its content:

> ;; Emacsen independent startup file.  All of the various installed
> ;; flavors of emacs (emacs 19, emacs 20, xemacs) will load this file
> ;; at startup.  Make sure any code you put here is emacs flavor
> ;; independent.

> ;; Package maintainers: do not have Debian packages edit this file.
> ;; See the policy manual for the proper way to handle Emacs package
> ;; initialization code.

Er, I said "content-free", not "comment-free".

Even so, there is a bug here.  "the policy manual" should be identified,
otherwise another two hours will be wasted by each person who tracks it
down, or more likely, who attempts to track it down.

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

> Configuration files such as site-start.el need to be in /etc by FHS,
> and by Debian policy.

<scream of rage> site-start.el typically goes in
/usr/local/share/emacs/site-lisp, according to the Emacs documentation.
So there is a conflict here between an upstream package's recommendations
and Debian's policies.  OK, it's not as bad as for qmail, but it exists.
I've got a lot of sympathy for qmail's author (Dan Bernstein)'s
insistence that qmail's files went into _exactly_ the same location in
any installation.

You seem to be taking the view that it's OK for Debian to completely
supersede upstream policies - you use the wording "need to be" rather
than the more accurate "ought to be".

I don't think this is OK at all.  It causes the waste of lots of lots of
people's time.  I think Debian has an onus to try and conform to upstream
package policies AS WELL AS its own.  For Emacs a solution is clear: put
/etc/... lower in load-path than /usr/local/share/.....

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

> The purpose is to make it possible for packages to work on specific
> versions of emacs, all versions of emacs, for users to modify the
> files and have their changes automatically respected, and to allow for
> add-on packages to be easily installed and automatically configured to
> work site-wide without the need for users to modify their own .emacs
> files or do anything else to deal with it.

OK, thanks!

> There may be better implementations of that complexity, but the
> features that it gives are necessary, ....

I'm trying to picture where this might be useful.  Typically, an Emacs
user on his home box is going to have exactly one version of (X)Emacs
installed, so the complexity will be a burden.  An Emacs hacker, such as
all of us, is going to have several, or even many, (X)Emacs versions
hanging around, in his own custom built directory structure, and will
probably have built these from source.  I can't see Debian's complexity
being useful for either of these (though I may be wrong).  A sysadmin
administering a mutil-hacker development shop would surely find it
useful.
 
> .... and frankly aren't something that upstreams spend much time
> contemplating.

You're not wrong there!

> Don Armstrong

-- 
Alan Mackenzie (Nuremberg, Germany).