unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Ludovic Courtès" <ludo@gnu.org>
To: Maxime Devos <maximedevos@telenet.be>
Cc: Guix-devel <guix-devel@gnu.org>
Subject: Re: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.
Date: Thu, 04 Aug 2022 10:51:31 +0200	[thread overview]
Message-ID: <87h72spf1o.fsf@gnu.org> (raw)
In-Reply-To: <c4c0a071-2e03-d4d6-6718-05424d21d146@telenet.be> (Maxime Devos's message of "Mon, 25 Jul 2022 05:17:33 +0200")

Hello!

Maxime Devos <maximedevos@telenet.be> skribis:

> Context: it's currently a mess:, and at times contradictory

As a rule of thumb, I’d suggest avoiding denigrating wording like this,
in an effort to keep communication smooth and effective.

>  * There is policy involving those three, as can be seen from the
>    shepherd mess.

What is “the shepherd mess”?  Realize also that not everyone may agree
that there is “a mess” in the first place.

The ‘shepherd’ package uses a snippet to fix a bug.  I think that’s akin
to applying a patch: the intent is that ‘guix build -S’ gives you the
code that’s actually built, with patches applied.

>  * This policy is partially secret, as can be seen by some people
>    treating some things as policy even if it's not in the manual.

There’s no secret, but there might be unwritten rules.

I think what we need to do is improve the “Snippets” section of the
manual, as you propose, so we don’t have unwritten rules and
misunderstandings based on hearsay.

[...]

> 20.4.5 Snippets, phases and patches
>
> Snippets, phases and patches at times serve overlapping purposes. To
> decide between the three, there are several considerations to keep in
> mind:
>
>  * Patches must not be used to remove non-free files, because a patch
>    by construction contains the non-free file itself so the patch would
>    be non-free, which would not be acceptable to Guix. Likewise,
>    patches should not be used to remove bundled libraries, to avoid
>    large space usage, but this is not an absolute rule unlike as for
>    non-free files.
>  * Snippets are often convenient for removing unwanted files such as
>    bundled libraries, non-free sources and binaries. It is technically
>    also possible to use phases for this, albeit slightly less
>    convenient at times. However, phases must not be used to remove
>    non-free sources, as then the output of "guix build --source" would
>    still contain the non-free sources, which is incompatible with Guix'
>    stance on free software. Likewise, phases should not be used to
>    remove binaries; however, this is not strictly forbidden.
>  * Snippets must not embed store items in the source, as this is
>    incompatible with cross-compilation and prevents effectively sharing
>    the source code produced with "guix build --source" with people
>    using non-Guix systems.
>  * In principle, you can apply a patch from a phase. However, this
>    causes the result of "guix build --source" to not correspond to the
>    actual source code anymore (i.e., it doesn't act as corresponding
>    source anymore), so consider this a last resort for situations such
>    as avoiding causing a world-rebuild for a patch fixing a
>    target-specific bug by making the patching conditional upon
>    target-foo?. If you apply a patch from a phase, make sure that the
>    patch appears in the inputs or native-inputs, such that "guix build
>    --source=all" will include the patch.
>
>    @c this relaxes the old rule a little
>
>  * Ideally, the source derived from the origin should be usable for
>    building on any system that the upstream package supports (even if
>    Guix does not support that system), as a courtesy to the people that
>    the source code is shared with. However, this is not an absolute
>    rule, most important is that it is usable on Guix and it is allowed
>    to neglect this recommendation when it is tricky to follow or a
>    large amount of work. For example, if some Windows-specific source
>    files are non-free, you can simply remove them without replacing
>    them by a free implementation, even if that would reduce the set of
>    systems the package can be built on.
>
> Sometimes, there remains more than one acceptable way to accomplish
> the goal. In that case, choose whatever appears to be most convenient.

I kinda agree with what Julien wrote.

I’d suggest starting with a patch against that section to address one
specific point that you think is the most pressing one.  From there we
can continue the discussion.

WDYT?

Thanks,
Ludo’.


  parent reply	other threads:[~2022-08-04  8:53 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-25  3:17 A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches Maxime Devos
2022-07-25  5:21 ` Julien Lepiller
2022-07-25 11:18   ` Maxime Devos
2022-07-25 11:37     ` Julien Lepiller
2022-08-04  8:51 ` Ludovic Courtès [this message]
2022-08-05  3:23 ` Philip McGrath
2022-08-05  8:13   ` Maxime Devos
2022-08-05  3:38 ` Philip McGrath
2022-08-05  8:09   ` Maxime Devos
2022-08-05 10:18 ` Maxime Devos
2022-08-05 13:59 ` v2: " Maxime Devos
2022-08-06  6:55   ` [PATCH] doc: Update contribution guidelines on patches, etc Liliana Marie Prikler
2022-08-06  6:55     ` [PATCH v2] " Liliana Marie Prikler
2022-09-02 13:12       ` Ludovic Courtès
2022-09-02 18:05         ` Maxime Devos
2022-09-05  9:47           ` Ludovic Courtès
2022-09-05 13:12             ` Maxime Devos
2022-09-05 16:05               ` Maxime Devos
2022-08-09 16:45     ` [PATCH] " Maxime Devos
2022-08-09 17:05       ` Liliana Marie Prikler
2022-08-09 18:19         ` Maxime Devos
2022-08-09 19:08           ` Liliana Marie Prikler
2022-08-09 20:30             ` Maxime Devos
2022-08-10  4:25               ` Liliana Marie Prikler
2022-08-09 20:40             ` Maxime Devos
2022-08-08 21:51   ` v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches Andreas Enge
2022-08-09 15:06     ` Maxime Devos
2022-08-09 17:10       ` Andreas Enge
2022-09-05 13:03     ` Maxime Devos
2022-09-07 12:17       ` Andreas Enge
2022-09-07 18:08         ` Maxime Devos
2022-08-09 18:58   ` david larsson
2022-08-09 20:53     ` Maxime Devos
2022-08-10 11:23       ` david larsson
2022-08-05 16:59 ` blake
2022-08-09 16:30   ` Maxime Devos
2022-09-05 14:06     ` Maxime Devos
2022-08-10  6:10   ` blake
2022-08-10  9:06     ` Maxime Devos
2022-08-10 10:33     ` blake
2022-08-10 10:44       ` Maxime Devos

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=87h72spf1o.fsf@gnu.org \
    --to=ludo@gnu.org \
    --cc=guix-devel@gnu.org \
    --cc=maximedevos@telenet.be \
    /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).