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 --]
next prev parent 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
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=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 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).