Hello, Am Fri, Aug 05, 2022 at 03:59:14PM +0200 schrieb Maxime Devos: > Here's a v2. I've changed the structure to something close to what Julien > proposed, it looks a lot better now to me!
thanks, it does! I still find it a bit too verbose compared to Liliana's suggestion, which I would prefer as a starting point of the discussion. > 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). Andreas