On Mon, Aug 30 2021, Andrew Tropin wrote:

>> Why would it be more consistent to make a separate package?  Making a
>> separate package is usually used for packaging a slightly different
>> version of the “regular” package, e.g., ‘emacs-next-pgtk’ adds native
>> compilation and pure GTK support for Emacs., ‘emacs-no-x’ removes X
>> suport for ‘emacs’.  ‘emacs-notmuch’ isn’t really a different version of
>> ‘notmuch’, it’s just ‘notmuch’ but with all the non-Elisp stuff
>> removed.  This is usually what using different outputs tries to achieve,
>> e.g., separate documentation from the main package, or in this case,
>> separate Elisp stuff from the main package.
>>
>
> Almost all elisp packages in Guix have a emacs- prefix, so as a user I
> expect to find notmuch*.el in emacs-notmuch package and notmuch binary
> in notmuch package, despite the fact that upstream distributes the
> source code for both of them in one tarball.

Good point, however, If we were to have separate ‘emacs-’ packages for
the packages that also contain Elisp stuff, should those packages still
include the Emacs package in their output, i.e., should the ‘notmuch’
package still include notmuch.el, or should the Elisp stuff only be in
‘emacs-notmuch’?

> Moreover, with emacs-notmuch and notmuch packages it's possible to use
> different build systems, which helps in automated package
> modification, for example I want to native compile all emacs packages
> or generate some additional metainformation, I just find all packages
> in my profile with emacs-build-system and modify phases accordingly.
> Yes, it's possible to do such modification for other packages
> manually, but it feels hacky and inconvinient.

This sounds like an interesting use-case, but I don’t know how useful
this will be for most people.