[bug#51307] [PATCH 0/2] guix hash: eases conversion

[zimoun]

Hi Ludo,

On Sat, 30 Oct 2021 at 16:53, Ludovic Courtès <ludo@gnu.org> wrote:
> zimoun <zimon.toutoune@gmail.com> skribis:
>
>>  2. Using the option recursive changes the result for tarball, as with:
>>
>>       $ guix hash $(guix build hello -S)
>>       0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i
>>
>>       $ guix hash $(guix build hello -S) --recursive
>>       1qx3qqk86vgdvpqkhpgzq3gfcxmys29wzfizjb9asn4crbn503x9
>>
>>     And I am not able to imagine a case.  To me, it should be a fixed-point.
>>     That’s what the first patch correct.
>
> That’s expected: ‘--recursive’ uses a different computation method,
> including file metadata (technically, it serializes the file as a nar
> and computes the hash of the nar).

Yes, but that’s odd.  It should be the same computation method for
tarballs.  Nothing is recursive for a tarball therefore, the option
should be skipped.  This proposal is perhaps not the best approach
although I lacked of imagination about corner cases.


>> Then, working on Disarchive which uses base16 as encoding, it is annoying
>> twice,
>>
>>   a) because it requires to download when all the sources
>>   b) because it sometimes requires to apply patches
>>
>> Compare,
>>
>>   $ guix hash $(guix build ceph -S)
>>   0ppd362s177cc47g75v0k27j7aaf27qc31cbbh0j2g30wmhl8gj7
>>
>> with the checksum in the package definition:
>> 0lmdri415hqczc9565s5m5568pnj97ipqxgnw6085kps0flwq5zh.
>>
>> With the second patch, it becomes easy to convert the checksum from upstream:
>>
>>   $ ./pre-inst-env guix hash ceph -f base16
>>   f017cca903face8280e1f6757ce349d25e644aa945175312fb0cc31248ccad52
>>
>> and nothing is downloaded.  Get the checksum of what Guix really builds is
>> done via the current way, for instance,
>>
>>    $ guix hash $(guix build ceph -S) -f base16
>>    473e4461e5603c21015c8b85c1f0114ea9238f986097f30e61ec9ca08519ed5e
>>
>> and the second patch allows to convert the checksum from the package
>> definition (without downloading).
>
> Ah yes, got it.  (I should read messages in the right order, oops!)
>
> An obvious problem with the interface you propose is that it’s
> ambiguous: are you printing the hash of the ‘ceph’ package, or computing
> that of the ‘ceph’ file?  I’m sure the Zen of Python has something on
> ambiguity.  ;-)

The patch is printing the hash of upstream and it is the only hash which
matters – speaking both about packaging and about Disarchive.
Therefore, there is no ambiguity here.  Better said, the ambiguity is
from “guix build --source” where it is not predictable beforehand what
it will return.

For instance, can you guess what “guix build -S graphviz” returns? ;-)
And can you guess the hash?


> Do you think there’s another place where we could provide helpers for
> the die-hard Disarchive hackers among us?  Maybe we could get ‘guix lint
> -c archival’ to print Disarchive URLs upon failure, and that’d already
> help?

To me, “guix hash” is about hashing therefore it appears to me the right
place for getting the hash of something.  For instance, I do not find
“guix lint -c archival” the right place for sending a request and saving
to SWH; as olasd said at the time, IIRC. :-) However, the good is that
“guix lint <pkg>” just works (for archiving). :-)

Last, I do not want Diarchive URLs upon failure, I would like hashes and
upstream URLs on request. :-)

Well, I do not know.  What could be better?  Another subcommand “guix
archival” doing all these plumbings: save, display hashes, upstream URL,
disarchive URL, etc.

WDYT?

Cheers,
simon