GNU bug report logs - #36614
rust@1.36's hash is incorrect.

Previous Next

Full log

View this message in rfc822 format

From: Ivan Petkov <ivanppetkov <at> gmail.com>
To: Tobias Geerinckx-Rice <me <at> tobias.gr>
Cc: 36614-done <at> debbugs.gnu.org
Subject: bug#36614: rust <at> 1.36's hash is incorrect.
Date: Fri, 12 Jul 2019 17:59:29 -0700

> On Jul 12, 2019, at 10:26 AM, Tobias Geerinckx-Rice <me <at> tobias.gr> wrote:
> 
> Yes, this is exactly what happened.  I consider this is a feature of Guix, even though it can feel like a gotcha sometimes.  :-)
> 
> We often tend to think of the source URL(s) as an ‘identifier’ of the source file.  However, it is nothing more than a hint about its *location*.  The only authoritative identifier of its *content* is the hash: to get *this file* (content hash), try looking *here* (location: URL).
> 
> One origin may have 0 or more source URLs: Guix will try them all until it downloads something matching the hash (and if even that fails it will try some implicit ones like tarballs.nixos.org).
> 
>   ‘Unique’ identifier (hash)
>     ├ maybe you can *find* it here (URL)
>     ├ or here (another URL)
>     ├ hell maybe here I don't know (yet another URL)
>     ⋮
>     Guix cares only about the content of the file; it doesn't care or even remember how it got it.  Or: if you change the download hint (release URL in this case), Guix won't care, because you didn't change the hash.
> 
> I hope that makes some sense,

This is a wonderful explanation, thanks! Will keep this in mind for the future :)

—Ivan

Previous Next

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