Subject: Re: bug#65979: incorrect “guix hash” for FastQC

From: Simon Tournier <[email-masked]>
Date: Tue, 26 Sep 2023 18:23:00 +0200

Hi,

On Tue, 26 Sept 2023 at 15:34, Ludovic Courtès <[email-masked]> wrote:

> There are two things are:
>
>   1. ‘vcs-file?’, used by ‘guix hash -rx’;
>
>   2. ‘git-fetch’, which does (delete-file-recursively ".git").

Yes.

> Clearly #2 is correct (it’s perfectly fine to have a ‘.svn’ directory in
> a Git repo), whereas #1 is an approximation that, in corner cases like
> this one, gives the wrong answer.

These corner cases matter for some SWH loader implementing Nar hashes
in Python.  Since they load sources.json (conversion of hash checksum
from package recipe), read the Nar hash and compare it with the one
they internal compute, then they need to implement in Python the
correct behavior.

See https://gitlab.softwareheritage.org/swh/devel/swh-loader-git/-/issues/4751#note_149180
and all the thread for context.

> My take is that it’s OK to keep ‘vcs-file?’ as is: the best we could do
> would be to add complicated heuristics in the hope corner cases like
> this one would be better dealt with, but it wouldn’t be bullet-proof
> anyway.

Well, the question is what other VCS as 'svn-fetch', etc. are doing?

Maybe, we can just have a special case for Git repository.

Somehow, since the problem needs to be solved for SWH, the same
solution applies for vcs-file? and "guix hash", no?

Cheers,
simon