Re: best gnu/linux distro for emacs

[Alan Mackenzie]

Hi, Bob.

Bob Proulx <bob@proulx.com> wrote:
> 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.

I've had a look at ./configure --help, and I don't think it documents
settings for `load-path'.  These paths are in src/epaths.h, which is
generated from src/epaths.in by (I think) ./configure.  I haven't yet
managed to find the precise mechanism which does this generation.

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

/usr/local/share/emacs is hard coded into src/epaths.in.

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

Yes.  But my personal build excludes some of the graphics libraries and
includes --with-gpm.

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

OK, point taken!  A distribution cannot build a "standard build" in that
sense, so I admit it's not all that appropriate a term.  Perhaps "vanilla
build" would be better.

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

We've been talking here all the time about binaries, not configuration
files.

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

You have a point here.  :-)  Where I take issue with the Debian maintainer
(of 2005) is in creating a content-free file /etc/emacs/site-start.el.
That couldn't help but cause problems with a common pre-existing seup.

> Bob

-- 
Alan Mackenzie (Nuremberg, Germany).