Re: Emacs per-package startup files

[Mark Eichin <eichin@cygnus.com>]

first, thanks for clearing up a lot of the arguments. This is the
first message I've seen that actually gives a justification for doing
something new and different...

re dynamically updating the same file -- I guess that does make sense,
and the lack of mechanism for /etc/services and inetd.conf has
actually caused me trouble recently.  (I'd take that as an argument
for *more* micromanagement scripts [it would make it easier to fix the
/etc/passwd problem that mhpower mentioned], but in those cases we
can't really change the "database" because of existing use, whereas
with emacs we are free to do that.)

You're right, rc.boot has worked pretty well. (I'm a little less
sanguine about rc?.d, but they *seem* to do the right thing...)

Hmm. As for dpkg needing install-elisp, I'm not quite sure I buy that,
because it would seem to argue that *any* install-* should be included
in dpkg. Then again, there is only install-info which *is* in dpkg,
and install-mime which is in mime-support which has it's own
justification. There aren't any others...

Hmm. Dpkg already does a good job with creating needed directories, as
well... so it would really be sufficient for any package to drop in an
emacs mode without actually having emacs installed yet. Interesting.

I guess the only thing unresolved is what directory to use, and what
the little bit of elisp should look like that scans the directory.
I'll look at the text explaining rc.d numbering to see what makes
sense for that. (I guess in theory we need the ordering, but in
practice, with autoload, do we need ordering here at all? certainly
none of the existing packages need it. But I suppose picking an order
at least makes debugging easier...)

So, do these files go in /var/lib/emacs, /etc/emacs, or
/usr/lib/emacs/site-lisp, and why?  I can set it up and send changes
to the emacs package maintainers this weekend if that gets worked
out...