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.