all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Leo Famulari <leo@famulari.name>
To: Julien Lepiller <julien@lepiller.eu>
Cc: 26718@debbugs.gnu.org
Subject: bug#26718: Update hexchat to 2.12.4
Date: Sun, 30 Apr 2017 16:05:34 -0400	[thread overview]
Message-ID: <20170430200534.GA27383@jasmine> (raw)
In-Reply-To: <20170430213539.789280bb@lepiller.eu>

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

On Sun, Apr 30, 2017 at 09:35:44PM +0200, Julien Lepiller wrote:
> What's the policy about using patches, snippet or build phases? I was
> recently asked to move code from snippet to build phase because it did
> not address a security issue or remove non free or bundled components,
> but I can't find anything documenting the choice we should make.

I don't know if we have a real "policy"; here are my thoughts.

Guix is a useful tool for acquiring free software source code to be used
outside of Guix, with `guix build --source`. Origin snippets and patches
affect the result of `guix build --source`.

Snippets are necessary for removing non-free bits from what is provided
by `guix build --source`. Without this, I think we'd run afoul of the
free system distribution guidelines (FSDG).

Then there are changes we make in order to port software to Guix or make
other relatively unimportant changes. If they can be done with a
sed-like / regex substitution, we do them in build phases. It's helpful
to keep them in Scheme, and we don't want to distribute them via `guix
build --source`.

Patches are for things that are difficult / opaque to do with a sed-like
tool. They are applied to the result of `guix build --source`. I also
like using patches when copying changes from upstream; the provenance of
the change can be made clear in the patch annotation. For this reason,
most of the security updates I push use patches, even if they are
one-liners. Maybe these changes aren't always helpful for users of `guix
build --source`, but I try to limit them to important bug-fixes.

I'm curious to hear others' thoughts on this subject!

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

  reply	other threads:[~2017-04-30 20:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-30 17:22 bug#26718: Update hexchat to 2.12.4 Julien Lepiller
2017-04-30 18:19 ` Tobias Geerinckx-Rice
2017-04-30 19:35   ` Julien Lepiller
2017-04-30 20:05     ` Leo Famulari [this message]
2017-04-30 21:11       ` Tobias Geerinckx-Rice
2017-05-01  7:52         ` Julien Lepiller
2017-05-05 20:21           ` Leo Famulari
2017-05-06 19:55             ` Leo Famulari
2017-05-06 21:08               ` Julien Lepiller
2017-05-06 22:02                 ` Tobias Geerinckx-Rice
2017-05-06  8:22 ` bug#26718: (no subject) Julien Lepiller
2017-05-06 13:48   ` Ludovic Courtès

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

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

  git send-email \
    --in-reply-to=20170430200534.GA27383@jasmine \
    --to=leo@famulari.name \
    --cc=26718@debbugs.gnu.org \
    --cc=julien@lepiller.eu \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.