Re: [bug#50077] Separate ‘emacs’ output vs separate ‘emacs-’ package (was Re: [bug#50077] [PATCH 1/3] gnu: notmuch: Add separate 'emacs' output.)

[Liliana Marie Prikler <leo.prikler@student.tugraz.at>]

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