Re: git-fetch without a hash

[Simon Tournier <zimon.toutoune@gmail.com>]

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