Re: best gnu/linux distro for emacs

[Bob Proulx]

Hi Alan,

Alan Mackenzie wrote:
> 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.

Mostly I expect that configure without options will root in /usr/local
but that software distributions will add --prefix=/usr and root it
there in the system directories instead.  The actual list of configure
options that are needed are pretty long.  I count 28 used in the
Debian version.  Mostly needed for setting up cross-compilation for
the various architectures.  But a few like --preix and --libdir so as
to locate the files in the desired place not in /usr/local.  Without
looking I would assume that many of those paths will work into the
load-path.  But some are apparently hard coded as you found.  I don't
know.  I just know what I would expect.

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

Interesting.  I am not sure that shouldn't be --prefix based.  If that
is hard coded then it won't relocate easily.

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

All good.  I was hoping we would be in agreement that a distribution
must add at least --prefix to configure and other options too so that
the result can be distributed and doesn't interfere with a local
compilation to /usr/local.  The two compilation configurations must be
different for at least some level or they will interfere.  The problem
lies in the right balance of everything.

For the most part I am pretty happy with Debian's packaging of emacs.
The unstable track stays pretty up to date with new versions as they
are released.  The stable track gets support as needed through the
lifecycle.  There is a rich variety of additions that I can simply
install and everything works.  Upgrades work simply and easily.

For the particular case of site-start.el I don't know.  By having the
packaged version in /etc/emacs it means that it keeps the system
version separate from a locally compiled version.  The two won't cross
unless a specific change is made to remove the /etc file.  They won't
use the same file unless something is done to make them use the same
file.  If that is done then the system emacs and a /usr/local locally
compiled version would share the same site-start.el file.  But if not
then they won't.

I don't know if that is the plan or just an accident.  But it seems
desirable to me.  I often turn people loose in /usr/local and say go
have fun and do whatever.  By design anything they do there won't
break something in /usr.  By default anyway.

Not everything on the system is that way.  For example Perl may have
additional modules installed in /usr/local and they will be pulled in
by default and may override the system ones.  Which is terribly
convenient!  But which plan is best?  I don't know.  There isn't one
canonical right for everything.

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

Wait.  We started out talking about the site-start.el file.  That is a
configuration file.  Or at least a local file for whatever elisp you
put there.  But it is definitely not a binary.

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

I don't know what the right answer is there.  But I would like to say
a few words about the problem in general for other packages.

Personally I agree with you that having a file with nothing but
comments is useless and undesirable.  I hate it.  If I never make a
change to it then all is okay.  I can upgrade the package and
(usually) that file will upgrade with the package.  But if I have made
local changes to the configuration file then upon upgrade I am
prompted to either select the package version or my version or to
merge the changes.  This is the Debian dpkg conffile system where
conffile changes are always preserved.  I know that rpm does things
differently.  (And I think less desirably.)

The package changes are almost always simply changes to the comments,
frequently flowing through from the upstream package.  Since I am
pedantic about such things I always take the fresh new version of the
configuration file and then redo my changes to it so that my copy is
as much in sync with the upstream as possible.  This is a manual
operation which is unneeded when the file is nothing but an empty
template of comments.  A drudgery.  And an unneeded one creating extra
work making it more annoying to me.

Whenever possible if a .d directory of config files is available then
I always make my customizations there in a uniquely named local file
that does not overlap with any packaged configuration file.  That way
the packaged configuration file is never edited.  This means that
upgrades can be fully hands-off.  It will upgrade and I won't ever
need to merge anything.

But since I read many of the bug lists for many of the packages I
frequently see users placing requests for package maintainers to
include an empty template file that has nothing but comments.  The
exchange usually goes like this.  User files a bug requesting a
template with all possible options commented.  Maintainer replies that
a full sample is available in /usr/share/doc/foo/example/foo.conf.
User responds that it is too much trouble for them to look there.
They won't know to look in the doc directory.  At least couldn't there
be a template that points to the full doc?  More discussion.  Back and
forth.  It is hard to argue against documentation.  Eventually the
maintainer relents and adds an empty template with nothing but
comments.

Time progresses and new packages roll through and the comments in the
original file have spelling errors that get fixed or other minor
stuff.  Perhaps new information is added.  Whatever.  The file is
updated.  Now upon upgrade I have to merge my local configuration with
the new version.  This happens with every upgrade.  I file a bug that
requests that the file be removed from the package.  But while it is
easy to add conffiles to a package it is quite a different thing to
remove them from it.  So it never happens.  And so the world becomes a
little bit worse to accommodate the naive user.  Sigh.

I have no idea if that is what has happened here or not.  But I have
seen it happen to other packages.

Bob