[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: git-fetch without a hash
From: |
Simon Tournier |
Subject: |
Re: git-fetch without a hash |
Date: |
Wed, 11 Jan 2023 16:34:41 +0100 |
Hi,
On Mon, 09 Jan 2023 at 12:16, Ludovic Courtès <ludo@gnu.org> wrote:
> Simon Tournier <zimon.toutoune@gmail.com> skribis:
>
>> Maybe my question is naive but what is the use case for this (sha256 #f)
>> in the first place? Because maybe it could just error using some
>> ’sanitize’ for the hash record field.
>
> There’s a couple of uses: Chromium, IceCat, and Linux-libre (IIRC).
>
> I don’t like that, but I’m not sure what it would take to change these
> to <computed-file> or something like that.
Well, from (gnu packages linux)
--8<---------------cut here---------------start------------->8---
(origin
(method computed-origin-method)
(file-name (string-append "linux-libre-" version "-guix.tar.xz"))
(sha256 #f)
--8<---------------cut here---------------end--------------->8---
and from (gnu packages gnuzilla)
--8<---------------cut here---------------start------------->8---
(origin
(method computed-origin-method)
(file-name (string-append "icecat-" %icecat-version ".tar.xz"))
(sha256 #f)
--8<---------------cut here---------------end--------------->8---
but not from Chromium, if I read correctly.
>From my understanding, we could have something like,
(sha256 (no-hash))
where ’no-hash’ would return a string, say
"0000000000000000000000000000000000000000000000000000" or whatever else
that would satisfy this hypothetical ’sha256’ sanitizer.
Cheers,
simon