guix-devel
[Top][All Lists]
Advanced

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

Re: v2: A proposal of a consistent set of clear rules and guidelines inv


From: Maxime Devos
Subject: Re: v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.
Date: Mon, 5 Sep 2022 15:03:34 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0


On 08-08-2022 23:51, Andreas Enge wrote:
20.4.5.3 Fixing technical issues (compilation errors, test failures, other bugs
...)
Usually, a bug fix comes in the form of a patch copied from upstream or another
distribution. In that case, simply adding the patch to the 'patches' field is
the most convenient and usually does not cause any problems; there is no need
to rewrite it as a snippet or a phase.
If no ready-made patch already exists, then choosing between a patch or a
snippet is a matter of convenience. However, there are two things to keep in
mind:
First, when the fix is not Guix-specific, it is strongly desired to upstream
the fix to avoid the additional maintenance cost to Guix. As upstreams cannot
accept a snippet, writing a patch can be a more efficient use of time.
Secondly, if the fix of a technical issue embeds a store file name, then it has
to be a phase. Otherwise, if a store file name was embedded in the source, the
result of 'guix build --source' would be unusable on non-Guix systems and
likely also unusable on Guix systems of another architecture.
Do you mean "phase" here instead of "snippet"? That is what I usually do...
My practice is to use a patch when the goal is to eventually change the
source code upstream (or it is already changed upstream and we can take a
patch from their git repo, say), and a phase when one cannot expect upstream
to incorporate the changes since they are specific to Guix (like embedding
store paths, as Liliana writes, where apparently a phase is the only option
anyway).

I meant 'snippet' in this subsubsection. Bugfixes seem useful to have in the result of "guix build --source", and appear to be required to be in there for the 'corresponding source' thing.

Greetings,
Maxime.

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]