GNU bug report logs - #50077
[PATCH 0/3] Various improvements to Notmuch

Previous Next

Full log

View this message in rfc822 format

From: Liliana Marie Prikler <leo.prikler <at> student.tugraz.at>
To: Xinglu Chen <public <at> yoctocell.xyz>, Andrew Tropin <andrew <at> trop.in>
Cc: 50077 <at> debbugs.gnu.org, guix-devel <at> gnu.org
Subject: [bug#50077] Separate ‘emacs’ output vs separate ‘emacs-’ package (was Re: [bug#50077] [PATCH 1/3] gnu: notmuch: Add separate 'emacs' output.)
Date: Wed, 01 Sep 2021 14:48:17 +0200

Am Mittwoch, den 01.09.2021, 14:05 +0200 schrieb Xinglu Chen:
> > IMO, notmuch package should not include Elisp stuff, at least I
> > don't see use cases, where it can be useful, but see where it can
> > be harmful.
> 
> Should this apply to other packages that contains Elisp stuff too, or
> is it specific to ‘notmuch’?
> 
> Cc’ing guix-devel to see what other people think before we start
> breaking people’s setups.  :-)
In my personal opinion providing a separate package (perhaps one using
emacs-build-system) is to be preferred as per the principle of least
surprise.  However, in some situations we might want to hold back on
that, e.g. if providing an extra emacs package would entail propagating
the original package just because.

On current master, there's quite a number of packages that require
mixing emacs-build-system into something else.  Reducing this number
would make changes to emacs-build-system cause less breakages, some of
which we've seen in the past and some of which could possibly happen in
the future, if e.g. post native-compilation we realize that we need an
extra phase to deal with <insert stuff here>.

TL;DR: I'm generally in favor of branching emacs support packages off,
even if origins are to be inherited.

Regards

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.