unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Andrew Tropin <andrew@trop.in>
To: Xinglu Chen <public@yoctocell.xyz>
Cc: 50077@debbugs.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 12:50:35 +0300	[thread overview]
Message-ID: <8735qozkt0.fsf@trop.in> (raw)
In-Reply-To: <87r1ebm503.fsf@yoctocell.xyz>

[-- Attachment #1: Type: text/plain, Size: 2703 bytes --]

On 2021-08-30 15:33, Xinglu Chen wrote:

> 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’?
>

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.

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

Even if there are not so many people, who do it right now or even in
some future, it's very likely that some derivative distribution with
considerable amount of users will appear, which will be utilizing such
capabilities.

Actually, the exact use case doesn't matter so much, but the whole
picture, where you need to track every package, which picks some phases
of one build system to make sure that your transformation of package
list works correctly is.  More regular and consistent package
definitions are, the easier and simplier to transform them
programmatically.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  reply	other threads:[~2021-09-01  9:51 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-16 14:10 [bug#50077] [PATCH 0/3] Various improvements to Notmuch Xinglu Chen
2021-08-16 14:12 ` [bug#50077] [PATCH 1/3] gnu: notmuch: Add separate 'emacs' output Xinglu Chen
     [not found]   ` <87o89owoi0.fsf@trop.in>
2021-08-28 10:34     ` Xinglu Chen
2021-08-30  7:14       ` Andrew Tropin
2021-08-30 13:33         ` [bug#50077] Separate ‘emacs’ output vs separate ‘emacs-’ package (was Re: [bug#50077] [PATCH 1/3] gnu: notmuch: Add separate 'emacs' output.) Xinglu Chen
2021-09-01  9:50           ` Andrew Tropin [this message]
     [not found]             ` <874kb4lcvf.fsf@yoctocell.xyz>
     [not found]               ` <456243eca955ecc83b26663ed4e7e22d5170f03d.camel@student.tugraz.at>
     [not found]                 ` <87sfynq2xm.fsf@zancanaro.id.au>
2021-09-03 16:14                   ` Xinglu Chen
2021-08-16 14:12 ` [bug#50077] [PATCH 2/3] gnu: notmuch: Build Info manual Xinglu Chen
2021-08-16 14:12 ` [bug#50077] [PATCH 3/3] gnu: notmuch: Use 'cc-for-target' instead of hardcoding 'gcc' Xinglu Chen
2021-09-04  9:41 ` [bug#50077] [PATCH v2 0/3] Improvements to Notmuch Xinglu Chen
2021-09-04  9:41   ` [bug#50077] [PATCH v2 1/3] gnu: notmuch: Build Texinfo manual Xinglu Chen
2021-09-04  9:41   ` [bug#50077] [PATCH v2 2/3] gnu: notmuch: Make cross-compilable Xinglu Chen
2021-09-04  9:42   ` [bug#50077] [PATCH v2 3/3] gnu: Add emacs-notmuch Xinglu Chen
2021-09-14  7:22     ` Andrew Tropin
2021-09-14 15:29       ` Xinglu Chen
2021-09-14 15:35         ` zimoun
2021-09-14 19:20           ` Xinglu Chen
2021-09-14  7:05   ` bug#50077: [PATCH v2 0/3] Improvements to Notmuch Nicolas Goaziou

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8735qozkt0.fsf@trop.in \
    --to=andrew@trop.in \
    --cc=50077@debbugs.gnu.org \
    --cc=public@yoctocell.xyz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).