Manoj Srivastava <[EMAIL PROTECTED]> writes: > If this analysis is correct, there is no bug in emacs (well, > there is nothing emacs21 packages can do to avoid this). Just don't > go removing dirs ;-). I generally put things in /usr/share/emacs/site-lisp, > which takes precedence over paths in /usr/share/emacs; and let the > files that belong to packages be (or remove the debian package, and > use the local package only).
I just finished reading the debian-policy thing on emacs. So have a little better idea what the game plan is now. I think there are some problems with it, but not really prepared to give a full analysis. One thing you might consider is that a regular emacs package from source would have had no problems with the directory having been moved. It would just have recreated it and gone on about its business. I noticed that my site-start.el file that has built up over a few years and worked in many places would not load as an init file even when placed in /usr/share/emacs/site-lisp. Which is contrary to emacs defaults. I had to change the name to `default.el' before it would load on init. It still doesn't load first, which again is not defaut and contrary to the emacs documentation (I think, but haven't researched it fully) While not major issues it seems a bad move to change stuff that is documented in the info files. Unless of course there is a good reason. A further thing I noticed in the policy statement was that some things are done by debian even if emacs is started -q -no-site-file. Which again breaks those commands and runs contrary to the documentation. That is supposed to give a fully vanilla emacs. Sometimes needed.
