Re: Debian's idiosyncratic complexification of Emacs

["Stephen J. Turnbull" <stephen@xemacs.org>]

Manoj Srivastava writes:
 > On Tue, 15 Jul 2008 08:50:21 +0200, David Kastrup <dak@gnu.org> said: 
 > 
 > > No, you don't understand: byte-compiled files should not go into
 > > /usr/local/share/emacs/site-lisp.  This directory is only incidentally
 > > named like a standard Emacs search path directory.  The byte-compiled
 > > files are to be in another directory so that list-load-path-shadows
 > > has something to think about.
 > 
 >         Which directory is that?

People here (with the exception of Stefan) have been very incautious
about distinguishing $prefix, /usr, and /usr/local.  Is that the issue
you refer to?

 > > And of course, any package installation that thinks it might work by
 > > placing .elc in the same place as .el is naive.
 > 
 >         Assuming you are not just trying to pick a fight, the problem
 >  that needs to be solved is this:

Emacs users and Emacs itself assume that the source for a compiled
library can be found in the same directory as the library itself.  If
as you and David imply, this is not true, the Debian installation
breaks standard practices of a great many long-time Emacs users.
These practices are taught to new users, too.

IOW, you've specified the problem incorrectly, at least if you want to
serve the traditionalists satisfactorily.

 > > And Emacs has a command byte-recompile-directory just by mistake.
 > 
 >         Emacs makes no attempt to cater to the issues facing third party
 >  elisp packages, so someone has to pick up where emacs developers stop.
 >  I have emacs 21, emacs 22, emacs-snapshot, and the latest XEmacs on
 >  this machine, and I also keep a non-debian git checkout emacs in
 >  /usr/local, and I have VM working flawlessly for all these flavours.
 > 
 >         If you have a better idea on how this should be done, please, I
 >  am all ears. Snarky remarks really do not help.

I don't have a better idea.  As David recommends, I'm a xemacs.deb
refusenik, with either a dummy (unused in daily work) installation or
even a virtual installation (ie, an empty package that provides the
emacs virtual package to keep dpkg happy).

The problem (for Debian) that you describe is real, and important.
There are an awful lot of Debian users who just want Emacsen to work,
and who keep all their personal development in .emacs, until it gets
accepted to the mainline.  There are multi-user, multi-Emacs hosts,
and certainly Lisp package maintainers need them.  The system works
well for them AFAICS, with the exception that some XEmacs users want
to use a few XEmacs packages from our archive, and that doesn't mix
well with a Debian installation.

However, trying to work with a Debianized X?Emacs in Emacs development
certainly creates a substantial burden.  Joe made the point that a lot
of stuff that's in many site-start.els doesn't belong there.  Well,
yes and no.  On my personal system, it *is* *my* site, and if I choose
to organize my .emacs by putting stuff that's relevant to all my users
in site-start, and stuff that's relevant only to root, mailman,
postgres, and my personal user respectively in .emacs, it is none of
Debian's business.  Debian's load-path and .d startup infrastructure
is pretty baroque (though easy to understand once you understand the
.d startup infrastructure in *any* context).  Navigating it in case of
a bug that manifests in a Debian install can be quite annoying.

Sure, it can be worked around, but I found it too great a burden for
the benefits, considering that most of the work would be duplicated by
Debian's Lisp package maintainers anyway.