[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debian's idiosyncratic complexification of Emacs

From: Karl Fogel
Subject: Re: Debian's idiosyncratic complexification of Emacs
Date: Mon, 21 Jul 2008 17:26:54 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

Manoj Srivastava <address@hidden> writes:
>> Or if the problem is that Debian isn't allowed to touch anything under
>> /usr/local/, then put code in /etc/emacs/site-start.el that loads
>> /usr/share/.../site-start.el and /usr/local/share/.../site-start.el
>> (and same for any other potentially blocked 'site-start.el's).
>         While Debian maintainers can not touch anything under
>  /usr/local, Debian install emacs with the PREFIX=/usr, and
>  /usr/share/emacs/site-lisp/site-start.el Could be made to load the file
>  under /etc.
>> Wouldn't that solve all the problems here?
>         Either the symlink or the modified version put in
>  $PREFIX/share/emacs/site-lisp/site-start.el will solve the issue, yes. 

I think we're almost there.

The trick is not to load the one in /etc, but to have the one in /etc
load whatever other ones exist -- some of which may be user-produced and
shadowed by the one in /etc.

The problem, IIUC, is that Emacs loads the first site-start.el it finds
in load-path, and no others.  Since the /etc one is Debian-maintained,
it is free to find the others (in likely places) and load them.  As long
as it does so last, everything will work out fine: user-created code
will be evaluated after Debian-created code, which is what we want.

>> Do you need a bug filed at bugs.debian.org, or is this email enough?
>         I'll file the bug report. Mind you, I am not the maintainer, so
>  I can't guarantee how fast it will be acted upon, but I'll at least put
>  in a pointer to this discussion in my bug report.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]