Re: Emacs per-package startup files
Brian C. White writes (Re: Emacs per-package startup files): ... [someone:] 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... I'd vote for /usr/lib/emacs/site-lisp. Why? Because /var/lib/emacs is for files that can't be on a read-only filesystem and /etc/emacs is for user config files and the like. /usr/lib/emacs/site-lisp is for something entirely different. It's for the main lisp files (modes or whatever) that a package installs. /var/lib is obviously wrong, as the files aren't changed in normal operation. The files need to be conffiles so that the sysadmin can modify their behaviour, remove them, c, and have their changes respected. So it needs to be in /etc. Ian.
Re: Emacs per-package startup files
[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.
Re: Emacs per-package startup files
Mark Eichin writes (Re: Emacs per-package startup files): ... [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.) Right, that was my line of thought exactly. ... 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... If anyone writes others I'll be happy to include them in dpkg, provided that they're GPL'd. ... 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... It needs to be in /etc, and the files must be conffiles, so that sysadmins can edit them and so forth. I suggested /etc/emacs/site-start.d because we already have one Emacs /etc file and /etc is already full of stuff. 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. How about making /usr/lib/emacs/site-start.el a file rather than a symlink, and having it load /etc/emacs/site-start.el and run /etc/emacs/site-start.d. 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...) If you just sort the filenames before you run them you'll get the ordering for free, and if we say that people who don't know what number to use or don't think they have ordering constraints use 50 then if we do decide we want something loaded early we can do it. Ian.
Re: Emacs per-package startup files
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... I agree that install-elisp should be the responsibility of emacs. Packages that want to use it should put an if [ -x /sbin/install-elisp ] then [...] fi around the install/uninstall code. This will allow packages to take advantage of it if available, but not actually depend on emacs being installed. This is the line I've taken with mime-support. There is a disadvantage that installing emacs after installing a package (p) that tries to call install-elisp will mean that p is completely unknown to emacs until p is either reinstalled or upgraded. I personally don't see this as a problem as upgrades happen fairly regularly. Of course, the above problem only exists if install-elisp does some setup work, as install-mime does. 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... I'd vote for /usr/lib/emacs/site-lisp. Why? Because /var/lib/emacs is for files that can't be on a read-only filesystem and /etc/emacs is for user config files and the like. Brian ( [EMAIL PROTECTED] ) --- In theory, theory and practice are the same. In practice, they're not.
Re: Emacs per-package startup files
Erick Branderhorst writes: If the files there really depend on each other, then it may be nice to require that each .el file contains (provide 'site-start-xxx) (as the *last* line so nothing is provided in case of error), and other files will just use (require 'site-start-xxx) as needed. Nice of course but now it happens that package A require stuff from B to be loaded, but this code for A is always executed before the stuff from B is executed and so A fails unless, the load process is run again and checks are made whether something needs to be loaded or if it has been loaded in an earlier run. That's wrong. If A requires stuff from B we'll have something like: ; package a (require 'site-start-b) ; do things here... (provide 'site-start-a) and ; package b ; do things here... (provide 'site-start-b) Now whatever the order packages are loaded, it works. If we load a, we get - a starts interpreting - a requires b - b starts interpreting - b ends providing site-start-b, so a's require is fullfilled - a continues interpreting - a ends providing site-start-a and if b was already loaded b is not loaded again. The only problem would be with circular dependencies, but then nothing can help you in such cases... Yves. P.S.: Erick, I read the list. No need to send emails twice.
Re: Emacs per-package startup files
IJ == Ian Jackson [EMAIL PROTECTED] wrote: IJ /etc/emacs/site-start.d ? There would be something else inside /etc/emacs or just site-start.d? If not, it seems we need a better name. /etc/site-start.d? /etc/emacs.d? /etc/emacs-start.d? /etc/emacs-lisp.d? Yes, I know would nice to have something that looks like site-start.el. Ciao, Emilio. -- Emilio C. Lopes mailto:[EMAIL PROTECTED] Instituto de Fisica da Universidade de Sao Paulo Caixa Postal 66318, 05389-970 Sao Paulo - SP, BRAZIL Phone: (+55) (11) 818-6724 (Voice) / 818-6715 (Fax)
Re: Emacs per-package startup files
EB == Erick Branderhorst [EMAIL PROTECTED] wrote: EB How will these files be read. In alphabetical or fileposition order? EB Some scripts written in these might work only properly if some other EB script is executed first. I can't come up with some proper example EB but I can imagine that this might be very true. This will force us EB to scan the files several times and execute what is in there only if EB some specific other scripts are executed earlier. Maybe they could be eval'ed following some number scheme, a la init. Ciao, Emilio.
Re: Emacs per-package startup files
Erick Branderhorst writes: OK, so we've decided to have packages put their Emacs startup stuff in a directory, with one file per package. The directory obviously ought to go in /etc, and the files made conffiles, so that the sysadmin can reconfigure things. /etc/emacs/site-start.d ? Please wait a minute. How will these files be read. In alphabetical or fileposition order? Some scripts written in these might work only properly if some other script is executed first. I can't come up with some proper example but I can imagine that this might be very true. This will force us to scan the files several times and execute what is in there only if some specific other scripts are executed earlier. If the files there really depend on each other, then it may be nice to require that each .el file contains (provide 'site-start-xxx) (as the *last* line so nothing is provided in case of error), and other files will just use (require 'site-start-xxx) as needed. Or is there a reason not to do that? Yves.
Re: Emacs per-package startup files
If the files there really depend on each other, then it may be nice to require that each .el file contains (provide 'site-start-xxx) (as the *last* line so nothing is provided in case of error), and other files will just use (require 'site-start-xxx) as needed. Nice of course but now it happens that package A require stuff from B to be loaded, but this code for A is always executed before the stuff from B is executed and so A fails unless, the load process is run again and checks are made whether something needs to be loaded or if it has been loaded in an earlier run. Erick
Re: Emacs per-package startup files
OK, so we've decided to have packages put their Emacs startup stuff in a directory, with one file per package. The directory obviously ought to go in /etc, and the files made conffiles, so that the sysadmin can reconfigure things. /etc/emacs/site-start.d ? Please wait a minute. How will these files be read. In alphabetical or fileposition order? Some scripts written in these might work only properly if some other script is executed first. I can't come up with some proper example but I can imagine that this might be very true. This will force us to scan the files several times and execute what is in there only if some specific other scripts are executed earlier. Sorry not native english speaker, so the above might be too cryptic, but I see some problem here. We might be better of with some script modifying a file like install-info does and have some order where scripts can be put in that file (top, middle, bottom, or 0..9). Erick
