GNU bug report logs - #65979
incorrect “guix hash” for FastQC

Previous Next

Full log

Message #17 received at 65979 <at> debbugs.gnu.org (full text, mbox):

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 65979 <at> debbugs.gnu.org
Subject: Re: bug#65979: incorrect “guix hash” for FastQC
Date: Tue, 26 Sep 2023 18:23:00 +0200

Hi,

On Tue, 26 Sept 2023 at 15:34, Ludovic Courtès <ludo <at> gnu.org> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.