[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] doc: Update contribution guidelines on patches, etc.

From: Maxime Devos
Subject: Re: [PATCH] doc: Update contribution guidelines on patches, etc.
Date: Tue, 9 Aug 2022 20:19:09 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0

Am Dienstag, dem 09.08.2022 um 18:45 +0200 schrieb Maxime Devos:
On 06-08-2022 08:55, Liliana Marie Prikler wrote:

+If your package has a bug that takes multiple lines to fix,
I don't think this is true for replacing all instances of "foo" by 
"/gnu/store/.../bin/foo" in a file.
Should it?
I don't think so. Directly substituting all the instances instead of first writing a patch that does "foo" -> "@foo@" or such seems simpler to me.  This might be a bit too nit-picky though, maybe it's clear from context that this is not the kind of fix meant by that line.
+ Furthermore, as with patches, modifying the snippets causes two
derivations to be built.
This is true, but I don't think reviewers and package authors have to
worry about that.
It does make a difference to the author when debugging their package. 
Starting with a phase and then moving it to a snippet can save good
Hm, maybe, I guess I often work on 'small' packages where it doesn't matter much.

On 09-08-2022 19:05, Liliana Marie Prikler wrote:
+Such changes include, but are not limited to, fixes of the build
+script(s) or embeddings of store paths (e.g. [...])

Is that how to English comma?  Sorry, I'm not a native speaker so I get
somewhat weirded out by the when to skip/not to skip rules.

Neither am I. English doesn't seem to do "rules" much. I do think, however, that adding a comma after "to" makes things a bit simpler to read here, and it doesn't appear to be ungrammatical -- at least, in licenses "but is/are not limited to" is often used that way.

Derivations are a rather low-level concept, could they be avoided in
the origin and phases documentation?
I don't quite see how.  You could s/source derivation/the result of
@code{guix build -S}/, but I don't think that's much better.

To be clear, do you mean you:


Also, "guix build -S" returns the source code (after snippet / patch, if any), not its derivation. For the latter: "guix build -S -d"

+Build phases are limited in that they do not modify the source
+derivation.  Thus, they are inadequate for changes that are to be
+reflected in the source code.  On the other hand, they only cause
+single rebuild and are thus slightly easier to debug than phases
See Andreas' comment on phase->snippet.

Also, do I understand correctly that the argument here is that
'single rebuild -> less compilation time -> easier to debug'?
Easier to debug for the package author currently fiddling with the
phase/snippet.  Not really a statement in any direction otherwise.
I don't see how "slightly easier to debug than phases" follows from "they cause only a single rebuild". My guess was that the intermediate step was lower compilation time, but apparently this was not the argument. As such, I'm not following.


Attachment: OpenPGP_0x49E3EE22191725EE.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]