Re: News from the emacs-snapshot packaging
On Wed, 03 Dec 2003 22:25:50 -0500, Peter S Galbraith <firstname.lastname@example.org> said:
> Jérôme Marant <email@example.com> wrote:
>> Manoj Srivastava <firstname.lastname@example.org> writes:
>> > On Mon, 01 Dec 2003 15:23:18 -0500, Peter S Galbraith
>> > <email@example.com> said:
>> >> Since using e.g. /etc/emacs21/ instead of /etc/emacs/ makes
>> >> these packages incompatible with future versions of Emacs, they
>> >> should really only be used when the setup is very different
>> >> between Emacs flavours. Even then, is there a good reason for
>> >> using them instead of using conditionals under /etc/emacs/ ?
>> > Umm, why would they be incompatible? When there is an emacs22,
>> > it shall have a flavour of emacs22, and the gnus install shall,
>> > if the compilation succeeded, create an init file in the
>> > appropriate place.
>> I don't think so unless gnus is emacs22-specific. It works pretty
>> well with other packages, I don't see any reason why it wouldn't
>> work with gnus.
> Right. I created a flavour emacscvs and ran:
> /usr/lib/emacsen-common/emacs-install emacscvs
> Investigating, I see it didn't work because you assume to know all
> flavours in /usr/lib/emacsen-common/packages/install/gnus. It's a
> valid point of view, since those are the flavours that you know to
> work and support. It's likely that your using the separate
> directory structure isn't causing problems as I had assumed (I now
> assume that ucf would create /etc/emacscvs/site-start.d if it didn't
> exist, but I haven't checked).
Debian emacs policy requires that all flavours of emacsen
provide, and support, the flavour specific startup directory.
And no, ucf shall not create that directory, but a supported
flavour of emacs would have the site-start.d directories in the first
place, as per Debian Emacs policies. (i.e., if the flavour emacscvs
wants to be supported by Gnus, it would do this).
> So I guess Jérôme can release emacs-snapshot to experimental and
> we'll have to find all packages that hard-wire byte-compilation
> flavours (like gnus) to have them add emacs-snapshot after checking
> that they work. Would that be okay with everyone?
I have no objections to adding flavours after I have tested
them, and am comfortable with the idea of supporting that flavour.
>> >> think it is not the right thing, unlike nxml-mode which is
>> >> really emacs21-specific.
>> > Well, I beg to differ. This prevents, say, from a package
>> > which only compiles for version 20, for example, from creating a
>> > load time config for emacs21, thoguh the byte compiled package
>> > is not available.
>> Why can't the flavour and its version be detected from the
>> /etc/emacs/site-start.d file, and things loaded (or not)
> That's what I do anyway.
This puts code that needs be run on every emacsen startup,
even ones that are not supported. I fail to see the benefit.
> So you used this structure because gnus didn't work on emacs19?
Well, the actual incident that prompted tis mechanism is now
lost in the mists of time (I am not even sure that it was Gnus and
not VM). But as long as I am responsible for bug reports on the
packages, I would much rather have a modicum of control over what I
am signing up to support.
Cheit's Lament: If you help a friend in need, he is sure to remember
you-- the next time he's in need.
Manoj Srivastava <firstname.lastname@example.org> <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