Re: Generated patches change over time

[Ludovic Courtès]

Mark H Weaver <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>
>> Maxim Cournoyer <address@hidden> skribis:
>>
>>>>> address@hidden (Ludovic Courtès) writes:
>>>
>>>>Lesson learned: we should not rely at all on generated patches because
>>>>they are bound to change frequently (version string at the end, length
>>>>of commit hash prefixes, etc.)  It’s probably worse than tarballs
>>>>generated by Git hosting services.
>>>>
>>>>So we should probably work towards using local copies of patches,
>>>>unless
>>>>we find that the generated patches do not include any variable bits.
>>>>
>>>
>>> Maybe we could pass the patches through some sanitizer to strip any 
>>> metadata? I guess the content itself shouldn't change?
>>
>> We can’t really do that, or the downloads would no longer be
>> fixed-output derivations and thus we wouldn’t be solving the problem.
>
> Can you elaborate on why it cannot be done?  If I understand correctly,
> our 'git-fetch' origin type deletes the .git subdirectory after fetching
> it, and yet it still creates fixed-output derivations, no?  I don't see
> why stripping metadata from a patch is fundamentally any different.

You’re right, along the same lines, it could be a fixed-output
derivation.

The problem is rather that the workflow would be a bit awkward: ‘guix
download’ would download the raw, unprocessed patch, and thus it would
give you the “wrong” hash.

In essence you’d have to put a random hash in your package definition,
run “guix build -S”, copy the correct hash from the error message,
manually look at the patch, etc.

It’s possible, but it’s a bit awkward IMO.

Or we would need to add a ‘--strip-patch-metadata’ option to ‘guix
download’ so that it applies the exact same transformation when
downloading.

Thoughts?

Ludo’.