Re: Bug#193439: emacsen-common: debian-emacs-policy and package setup in conffile
Manoj Srivastava <srivasta@debian.org> writes:
>>> A, this is against policy; users need to be able to modify _all_
>>> configuration matter.
>
>> I don't follow this argument. I agree that users should be able to
>> modify all configuration matters, but I don't see how it relates to
>> putting the package bootstrap code under the complete control of the
>> package itself?
>
> Several of the startup files in fact set variables, and modify
> package behaviour to suit Debian's needs. I see
Yes, but that could be conditioned on:
>> One solution to keep users in full control, with the above idea,
>> would be to condition the bootstrap code on a variable that can be
>> set by the user earlier in the startup process. Another solution
>> would be to allow users to override the
>> /usr/share/emacs/debian-lisp.rc/foo.el by creating a
>> /etc/emacs/site-start.d/foo.el file.
>
> Ach. Why not the far simpler solution of letting the startup
> files be configuration files, which they are, really. If they are not
> configuration files, why are they being loaded?
Yes, it works, but it is slow, since the file would need to check if
the package is still installed before evaluating some expressions.
That is why I'm arguing for a different solution.
> I would not have things being loaded into my emacs that I did
> not want -- and making the file accessible to user mods allows for a
> far finer grained control than a all-or-nothing approach.
>
>>> Why not just write correct startup files, that know when the
>>> package is gone?
>
>> If implemented like it was suggested earlier in this thread, the
>> reason is that it slows down the debian emacs startup time even
>> more.
>
> I am afraid I do not recall what that was, and I do not ahve a
> copy handly.
Peter S Galbraith <psg@debian.org> wrote:
> Here's what I've decide to do with `emacs-goodies-el' :
>
> (if (not (file-exists-p "/usr/share/emacs/site-lisp/emacs-goodies-el"))
> (message
> "Package emacs-goodies-el is removed but not purged. Setup not done.")
> (debian-pkg-add-load-path-item
> (concat
> "/usr/share/" (symbol-name flavor) "/site-lisp/emacs-goodies-el"))
> (require 'emacs-goodies-el))
> Does a file existence test really slow down emacs startup that
> much?
Compare XEmacs and Emacs startup time when /usr/share is on a network
file system. Compare pure Emacs startup time with Debian Emacs
startup time.
XEmacs iterates through all packages and loads the auto-autoloads.el
file. This is similar to the current Debian situation (if the
/etc/emacs/site-start.d/ scripts are written to only autoload things
-- at least some debian packages used to load the entire package at
startup time, which is even worse). Adding one or more file existence
checks per installed package will slow things down.
Recently, changing the build system of Gnus was discussed, and the
(supposedly) correct solution to fork one emacs per file to byte
compile was problematic since debian emacs startup is slow.
Of course, benchmarking the above solution before rejecting it would
give hard facts to look at, but since I think that the debian emacs
startup time is unusable long even today, I believe that any change
that goes into this should reduce startup time, not increase it.
> Wouldn't that time be spent by emacs anyway looking for all these
> extra files to call at startup time?
What extra files? Evaluating
(autoload 'gtk-doc-insert "/some/path/gtk-doc" nil t)
(global-set-key "\C-x4h" 'gtk-doc-insert)
is sufficient to set up a gtk-doc elisp package, and does not load any
extra files at startup.
Reply to: