[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


> >> 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.  :-)


Reply to: