Emacs keeps a bunch of scripts to run at startup, in the directory </etc/emacs/site-start.d>.
These scripts were making the startup of my emacs painfully slow, so I moved most of them to a directory </etc/emacs/site-dontstart.d>.
All was well until the other day, when Debian (stable) released a new and more secure xemacs21 package. As part of this package's installation process, a program called emacs-install gets run. After spending (I think correctly) a huge amount of time compiling bits of Lisp, emacs-install died, complaining that it wasn't finding the startup scripts where it expected, leaving me unable to complete the installation. Is there some "official" method of disabling the startup scripts that doesn't cause this problem, please?
(I'd also quite like to know the answer to the same question, with respect to the system startup symlinks in </etc/rc?.d>.)
Dan Hatton dan.hatton@btinternet.com writes:
Emacs keeps a bunch of scripts to run at startup, in the directory </etc/emacs/site-start.d>.
Specifically, emacs add-on packages put them there.
These scripts were making the startup of my emacs painfully slow, so I moved most of them to a directory </etc/emacs/site-dontstart.d>.
All was well until the other day, when Debian (stable) released a new and more secure xemacs21 package. As part of this package's installation process, a program called emacs-install gets run. After spending (I think correctly) a huge amount of time compiling bits of Lisp, emacs-install died, complaining that it wasn't finding the startup scripts where it expected, leaving me unable to complete the installation. Is there some "official" method of disabling the startup scripts that doesn't cause this problem, please?
Remove the add-on packages that you didn't want?
On 9 Feb 2005, Richard Kettlewell wrote:
Remove the add-on packages that you didn't want?
That would solve the immediate problem, but what I really like is to have the packages available to load on command, but not to load automatically on Emacs startup.
Dan Hatton dan.hatton@btinternet.com writes:
Richard Kettlewell wrote:
Remove the add-on packages that you didn't want?
That would solve the immediate problem, but what I really like is to have the packages available to load on command, but not to load automatically on Emacs startup.
That's pretty much what those files are for.
Presumably this is a fairly slow machine? I find GNU Emacs 21 starts up in under a second even with about twenty such files - certainly quickly enough that I don't care about the wait. (It may help that I generally leave it running for a long time rather than constantly restarting it.)
On 10 Feb 2005, Richard Kettlewell wrote:
That's pretty much what those files are for.
Presumably this is a fairly slow machine? I find GNU Emacs 21 starts up in under a second even with about twenty such files - certainly quickly enough that I don't care about the wait. (It may help that I generally leave it running for a long time rather than constantly restarting it.)
OK. Sounds like the main points are: no, there's no flashy "official" way of disabling the startup scripts, and my hack of moving the ones I don't want to another directory is vaguely sensible. I can work around the xemacs21 installation problem by temporarily re-enabling them all.
Dan Hatton wrote:
Emacs keeps a bunch of scripts to run at startup, in the directory </etc/emacs/site-start.d>.
Is there some "official" method of disabling the startup scripts that doesn't cause this problem, please?
(I'd also quite like to know the answer to the same question, with respect to the system startup symlinks in </etc/rc?.d>.)
Have you had problems with the symlinks? Unless you delete the appropriate file in /etc/init.d then I can't imagine APT having any problems with the symlinks being missing. Unless it's a bug, of course ;-)
beb
On Wed, 9 Feb 2005, BenEBoy wrote:
Have you had problems with the symlinks? Unless you delete the appropriate file in /etc/init.d then I can't imagine APT having any problems with the symlinks being missing. Unless it's a bug, of course ;-)
Not such serious problems: just that, every time a package with an init script gets updated, apt recreates the symlinks I'd (intentionally) deleted or moved.