Re: v2: A proposal of a consistent set of clear rules and guidelines involving snippets, phases and patches.

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1.1.1.1: Type: text/plain, Size: 1847 bytes --]


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 #1.1.1.2: Type: text/html, Size: 2301 bytes --]

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]