Maxim Cournoyer <maxim.courno...@gmail.com> writes:
> l...@gnu.org (Ludovic Courtès) writes:
>
> [...]
>
>> 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.
>
> The way I see it, `guix download' should just do the right thing -- the
> metadata stripping should be baked in and not user
> controllable. Alternatively, it could be controllable, but enabled by
> default. This would keep the workflow the same as it is now.
I *certainly* don't want "guix download" to try to automatically detect
that the downloaded file contains a patch, after some possibly
nontrivial amount of plain text which is typically present in patch
files, and to canonicalize the patch in that case.
However, we could add an optional flag to "guix download", or perhaps
add another 'guix' subcommand, to request the use of a specific 'origin'
type. In addition to supporting canonicalized patches, this could also
improve the workflow for other origin types such as 'git-fetch' and
'hg-fetch'.
In general, the specified 'origin' type would determine the number and
meaning of the arguments, e.g. for 'git-fetch' an additional commit
argument would be needed.
Thoughts?
Mark
