Re: Bug#193439: emacsen-common: debian-emacs-policy and package setup in conffile
On Fri, 16 May 2003 23:29:31 +0200, Simon Josefsson <firstname.lastname@example.org> said:
> Manoj Srivastava <email@example.com> writes:
>> On Fri, 16 May 2003 16:37:39 +0200, Simon Josefsson
>> <firstname.lastname@example.org> said:
>>> 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.
>> 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
> 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?
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
I am afraid I do not recall what that was, and I do not ahve a
copy handly. Does a file existence test really slow down emacs
startup that much? Wouldn't that time be spent by emacs anyway
looking for all these extra files to call at startup time?
"Say yur prayers, yuh flea-pickin' varmint!" Yosemite Sam
Manoj Srivastava <email@example.com> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C