[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65979: incorrect “guix hash” for FastQC
From: |
Ludovic Courtès |
Subject: |
bug#65979: incorrect “guix hash” for FastQC |
Date: |
Sun, 01 Oct 2023 17:07:01 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) |
Hi,
Simon Tournier <zimon.toutoune@gmail.com> skribis:
[...]
>> 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.
I agree, SWH needs something more robust than ‘vcs-file?’.
>> 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?
Remove the relevant metadata directory/directories.
> 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?
Yes, ‘guix hash’ uses ‘vcs-file?’.
Now, SWH does not use ‘guix hash’ (I suppose) so they’ll have to address
that on their side (in Python code I guess).
Ludo’.
- bug#65979: incorrect “guix hash” for FastQC,
Ludovic Courtès <=