Mark H Weaver <m...@netris.org> skribis: > l...@gnu.org (Ludovic Courtès) writes: > >> Maxim Cournoyer <maxim.courno...@gmail.com> skribis: >> >>>>> l...@gnu.org (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’.
