Re: PB with auctex-11.54 (debian testing) *THE END*

* Frank Küster (2005-01-27) writes:

> Ralf Angeli <[email protected]> wrote:
>
>> That's due to the Debian misconduct of adding
>> "/usr/local/share/emacs/site-lisp" to `load-path'.  It's specified
>> somewhere in their Emacs policy but dunno why.  The XEmacs I am using
>> is provided by Debian and I was bitten twice by it not finding the
>> right AUCTeX installation due to this stupidity.  I had to comment the
>> respective line in /etc/xemacs21/site-start.d/00debian.el.  If I knew
>> more about load-paths, I'd probably written a bug report.
>
> I don't see why this is stupid. How else can a local administrator
> install newer versions of files? I think it's even possible to use
> auctex installed in /usr/local/, just with a little tweaking of
> /etc/emacs21/site-start-d/50auctex.el. 

The problem is that most software packages don't follow the separation
scheme Debian uses.  AUCTeX and Gnus for example will install
themselves into /usr/local/share/emacs/site-lisp/ if configured for
Emacs and some XEmacs package directory if configured for XEmacs.  But
the XEmacs shipped with Debian will look into
/usr/local/share/emacs/site-lisp/ and find a package not intended to
be run with it and files byte-compiled with Emacs.  Assuming that
/usr/local/share/emacs/site-lisp/ is a directory holding only
uncompiled source files is out of touch with reality.

I think that administrators installing additional software for the
different Emacsen on their systems should be intelligent enough to
care for themselves about adapting load-path.  If Debian really wants
to add the /usr/local/ tree to the default load-path then they should
at least refrain from adding /usr/local/share/emacs/site-lisp/ to
load-path in XEmacs as the path is traditionally used for installing
Elisp files for Emacs.

-- 
Ralf