Jookia <166291@gmail.com> skribis:
Toggle quote (34 lines)
> On Thu, Jan 21, 2016 at 11:10:14AM +0100, Ludovic Courtès wrote:
>> Pjotr Prins <pjotr.public12@thebird.nl> skribis:
>>
>> > On Thu, Jan 21, 2016 at 09:50:18AM +0100, Ludovic Courtès wrote:
>> >> This is expected: origins are fixed-output derivations, meaning that it
>> >> does not matter how we perform them (using Git, over HTTP, or thanks to
>> >> an avian carrier), as long as the result has the specified sha256.
>> >>
>> >> Thus, when you change, say, the Git commit ID or origin ‘method’ without
>> >> changing the ‘sha256’ field, nothing happens: the daemon says “OK, I
>> >> already have a store item with that ‘sha256’, so I don’t do anything.”
>> >>
>> >> Clearly, one has to be cautious with this, it’s easy to mistakenly use
>> >> the old source.
>> >
>> > Hmmm. I thought the sha256 was calculated over the derivation +
>> > sources
>>
>> What you’re saying is true of the hash that appears in /gnu/store file
>> name, but I was referring to the ‘sha256’ field of origins, which is a
>> different thing.
>>
>> Ludo’.
>
> I think this is a bit of a problem even if it's expected: Often times we can't
> calculate the hash until it's downloaded and get a hash mismatch. The other day
> I rebuilt NixOS almost entirely on my machine and changed the revision on
> Firefox to a new branch but didn't change the hash since I expected a mismatch.
>
> Needles to say I realized what happened when I checked Firefox's version. I
> think it'd be great to have a 'INVALID' hash we can use for development that
> just prints a mismatch and errors out like usual. Maybe this is possible in
> Guix, but it didn't seem documented and it's not possible in NixOS.
The problem is that Guix cannot guess that the ‘sha256’ the developer
provided in the ‘origin’ form is actually wrong. Only the developer
knows.
This is mitigated in Guix by the fact that we usually include the
version string or Git commit ID in the origin’s file name, with patterns
like:
(define foo
(let ((commit "deadbeef"))
(package
(name "foo")
(version commit)
(source (origin
(method git-fetch)
(uri (git-reference (commit commit) …))
(file-name (string-append name "-" commit)) ;<– !
(sha256 …)
…))
…)))
The good thing with this pattern is that, when you modify the value of
‘commit’, you also end up modifying ‘file-name’, thus triggering a
re-download. So if you had forgotten to update ‘sha256’, you
immediately get a hash mismatch error.
In practice, I’ve found this to be rather helpful.
Additionally, ‘guix lint’ emits warnings for packages that do not follow
this pattern, hopefully making the problem that Pjotr describes less
likely.
Ludo’.
