Re: News from the emacs-snapshot packaging
Manoj Srivastava <srivasta@debian.org> wrote:
> > 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).
I now see that I do have /etc/emacscvs/site-start.d/ after all. So gnus
didn't get byte-compiled because you only process known flavours (which
is a legitimate point of view, but see below).
> > 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.
Good!
> >> Why can't the flavour and its version be detected from the
> >> /etc/emacs/site-start.d file, and things loaded (or not)
> >> accordingly?
>
> > 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.
Except that you are currently supporting all Emacs flavours in woody,
sarge and sid anyway.
> > 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.
Sure. I personally wouldn't file a bug report against a package that
didn't work correctly using my hand-packaged CVS Emacs. But I would be
happier to have elisp packages _not_ skip it altogether. If it breaks I
get to keep both pieces. :-)
Peter
Reply to: