Re: best gnu/linux distro for emacs

[Bob Proulx]

Alan Mackenzie wrote:
> Bob Proulx wrote:
> > What makes /usr/local/share/emacs/site-lisp/site-start.el the normal
> > path and /etc/emacs/site-start.el something not normal?
> 
> A very good question!  I've had a quick search of the Emacs manual and not
> found anything specifying the contents of load-path.  The next best thing
> was:
> 
> "Many sites put these files in a subdirectory named `site-lisp' in the
> Emacs installation directory, such as `/usr/local/share/emacs/site-lisp'."
> 
> , from the chapter "The Emacs Initialization File".  I'm confident that
> /etc/emacs exists nowhere in the manual.

I am a big believer in doing things the way it is documented.  But in
this case I am going to argue that the documentation was insufficient
to the task.  Because I think this is simply a case of the
documentation not sufficiently describing how emacs might be compiled
and installed.  Basically all of the stuff that we normally see in the
'configure' script set of options.  Things get messy where theory
meets practice and I can see the documentation trying to avoid getting
into that mess.  But here it has caused a problem.

> When I start emacs -Q, load-path contains the directories under
> /usr/local/share/emacs/24.3/lisp together with
> /usr/local/share/emacs/site-lisp.  So it would seem, for a standard build,
> that .../site-lisp is the only safe place for site-start.el.

You say "for a standard build" and I think that needs more
clarification.  What is a standard build?  Let me jump ahead and
assume this was your own compilation and that you did not supply any
configure options at all.  (Since I think that is likely the case
here.)  Then for you the "standard build" really meant a local
compilation and installation using all of the default configure
options.  Is that correct?

> > In any case...  One could always put the customizations in that file.
> > That is rather what is expected.  Or one could add a load statement
> > there to load /usr/local/share/emacs/site-lisp/site-start.el if you
> > want to keep the customizations there.  It is six of one or a half
> > dozen of the other.
> 
> GRRR!!!  Yes, one can do any of these things, but only after having
> discovered there's a problem which needs fixing, and diagnosing that
> problem.  This cost me, perhaps, an hour or two back in 2005 when I
> first installed Debian on a new PC, and my site-start.el wasn't loading.

This is really uncovering a deeper layer of philosophical question.
The question is how do you package software for distribution to a wide
audience of people?  Where do you put it?  How do you do this while
allowing people to compile and install their own software?  This is
the question that must be answered in order to address your issue.

A local compilation using the standard autotools and no configure
options will root all of the paths in the /usr/local tree.  Programs
will go in /usr/local/bin and so forth.  If that is the standard build
then should a software distribution (pick any) compile their software
using the same configure without any options and install in /usr/local
and so be a "standard build"?  [No.  Please no.]

Instead we have a separation with system packaged paths in / and local
user compiled paths in /usr/local.  We hold /usr/local inviolate
against system intrusion.  And the reverse is almost the same.  We
don't expect that if we compile and install to /usr/local that it will
smash over system package managed files in /.

Knowing this then if I am using a locally compiled program installed
in /usr/local/bin and want to modify its configuration then I expect
it to be configured in /usr/local somewhere usually /usr/local/etc but
sometimes elsewhere.  If I am using a system package installed program
in /bin (or /usr/bin) then I expect it to be configured somewhere in /
usually /etc but sometimes elsewhere too but definitely not /usr/local.

Bob