Re: Bug#193439: emacsen-common: debian-emacs-policy and package setup in conffile

[Simon Josefsson <jas@extundo.com>]

Package: emacsen-common

Peter S Galbraith <p.galbraith@globetrotter.net> writes:

> [You'll need to close the new you created by emailing to:
>  	Debian Bug Tracking System <submit@bugs.debian.org>
> ]

I could not find any new bug report.  Perhaps the BTS discovered I was
replying to an existing bug.

> Simon Josefsson <jas@extundo.com> wrote:
>
>> Peter S Galbraith <psg@debian.org> writes:
>> 
>> > 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))
>> >
>> > I have moved the bulk of setups in a separate file `emacs-goodies-el.el'
>> > that is not under /etc, but that's only because it contains a _lot_ of
>> > code.
>> 
>> Note that this will make emacs startup even slower; stat:ing O(k*n)
>> files instead of O(n) (where n is number of debian emacs packages you
>> have installed, and k depends on the number of additional
>> file-exists-p invoked).  Compare the startup time of Emacs and XEmacs
>> when /usr/share is a network file system to see that this leads to a
>> noticeable slowdown.  IMHO it would be better to simply treat the
>> /etc/emacs.d/ files as non-configuration files and remove them when
>> the package is removed, thus making it possible to make them contain
>> unconditional autoloads.  Even the current O(n) slowdown is so big I
>> rarely use the debian built emacs.
>> 
>> Just my $.2.
>
> Unfortunately, that's against Debian policy.
>
> What we need is an alternate directory that is _not_ under /etc
> where we could also put Emacs startup files.
>
> That would be the subject of a bew bug report.  :-)

I'm BCC:ing this to submit@bugs.debian.org, lets see what happens.

One solution would be to modify emacs to look for, before default.el
and site-start.el, a /usr/share/emacs/debian-lisp.el and have a
/usr/share/emacs/debian-lisp.rc/ directory which corresponds to
todays' /etc/emacs/site-start.d/ but is managed entirely by Debian
packages.  The files should contain the minimal amount of code
required to get a package up'n'running, and should assume the rest of
the package is installed.

Then /etc/emacs/site-start.d/ can be dedicated entirely to site
customizations, instead of being something where debian packages write
to but is unable to modify or remove in.  Having debian packages write
to something called "site" seems confusing to me, Emacs uses that term
for site local modifications.