Re: Bug#193439: emacsen-common: debian-emacs-policy and package setup in conffile
Manoj Srivastava <firstname.lastname@example.org> writes:
> This is what I have heard so far. In the current mechanism
> a) To correctly implement the configuration file, care must be taken
> to handle the removed-but-not-purged state, which requires a file
> existence test
To clarify: At least one file existence test per package, to a
possibly networked file system /usr/share.
> b) One needs to make sure that user changes are not discarded.
> a) The mechanism is already in place
> b) One can put in any code, not just auto loads, in the file loaded at
> In the new directory proposed, one can put autolodas etc in a
> non-configuration file that is loaded at startup
> a) This file is gone when the package is removed, so no file
> existence check is required
> b) Simple variable settings can be in the configuration file, and
> they shall not harm anything if the file remains after removing
> the package [Not strictly true, since there could be two
> competing packages that set the same variable, or reset a variable
> also used by upstream emacs -- I do not think simple variable
> setting are quite as innocent as this]
> a) This requires changes in the emacsen common infrastructure
> b) For anything other than autoloads, you probably still need
> something similar ot the current mechanism anyway -- setting the
> load-path, setting some variables that are not private to the
> package, creating derived modes, etc.
Emacs has subdirs.el, XEmacs has the packaging infrastructure. They
solve similar problems. Is there a need to reinvent those wheels?
> On the balance, I do not see the benefit. Is a file existence
> test so onerous? Does anyone have nay numbers on how long it takes?
XEmacs in Debian:
jas@latte:~$ time xemacs21 -q -batch 2>/dev/null | tail -n3
jas@latte:~$ time xemacs-21.4.12 -q -batch 2>/dev/null | tail -n3
Emacs in Debian:
jas@latte:~$ time emacs21 -q -batch 2>/dev/null | tail -n3
jas@latte:~$ time emacs -q -batch 2>/dev/null | tail -n3
This is on local file systems and when all of the data is in the
cache. A more realistic test would be to flush the cache and try
those commands again. Does someone know how to flush the kernel hard
disk cache on linux?
If the slowdown was a few percent, I wouldn't argue, but the Debian
emacs packages slows down startup by a few magnitudes now.