[EMAIL PROTECTED] writes ("Re: Emacs per-package startup files"): > Umm, /usr/lib/emacs/site-lisp/ is already there, and already the right > place for this sort of thing. Next question?
Err, I don't think so. Files in /usr/lib/emacs/site-lisp aren't loaded automatically (and shouldn't be). > As for ordering: use require, and then safe-append a section to > /etc/site-start.el, JUST LIKE EVERYTHING ALREADY DOES... we don't need > a new mechanism here, just some common simple automation of the one > that vm, w3, gnats, and others already use... Respectfully, I disagree. Experience with /usr/info/dir, inetd.conf, and indeed with site-start.el (/etc/site-start.el vs. site-lisp/site-start.el and symlinks, &c) has taught us, I feel, that it is a bad thing to have many different packages all dynamically update the same file just to add and remove their own little bits from it. Contrast this with /etc/rc?.d and /etc/rc.boot, where there has been little unfortunate interaction. There's the question of how to distinguish changes made to the shared file by the sysadmin from those made by package maintainer scripts. This is much easier if each package's bit is in a separate file - dpkg's conffiles mechanism can take care of it. There's also the question of having a standard tool. Obviously it would be good to have a standard tool for this kind of thing (a la install-mime and the rest). However, the more you do this the more of these little install-foo scripts you have, and the more stuff you drag in when you try to install the package. For example, supposing Emacs were to provide a script to add things automatically I couldn't use it, because dpkg can't depend on Emacs. The script would have to end up in dpkg itself. So, all in all, I think it would be better to have an arrangement where all the bits that packages would want to put in the site-start are installed as conffiles in a directory, and arrange that the real site-start runs every file in the directory a la run-parts. As for ordering: the entries in site-start aren't supposed to require much ordering. After all, they're autoload definitions and the like. I think a sequence numbering scheme like that for the other package-put-a-file-in-here directories would be quite adequate. Now Emacs is your (Mark Eichin's) package, so you get to decide how things are to be done. I still hope though that I (and others who may agree with me) can persuade you that these arguments have merit, and that it would be better and simpler in the long run if we started making this not particularly arduous transition. Either way I'd appreciate it if, when this discussion is concluded, you could send me some text for the new policy manual about how elisp should be managed. Thanks, Ian.