Non-deterministic package IDs are really bad in 7.10

[Mateusz Kowalczyk]

On 05/19/2015 06:46 AM, Daniel Peebles wrote:
> Don't Nix builds all happen in a randomly generated temporary directory by
> default? Then you just copy to $out in installPhase. Perhaps stabilizing
> the build directory would help alleviate some of the immediate problems, if
> what Joachim is describing affects us too.

Oh, I was far too hasty in reading the bug on the Debian tracker. Yes, I
suppose this could be a problem for us though I'd like to see it first
before trying to work around it.

> On Mon, May 18, 2015 at 10:13 PM, Mateusz Kowalczyk <fuuzetsu at fuuzetsu.co.uk
>> wrote:
> 
>> On 05/14/2015 05:43 PM, Joachim Breitner wrote:
>>> Hi,
>>>
>>> Am Sonntag, den 10.05.2015, 19:39 +0100 schrieb Mateusz Kowalczyk:
>>>> I'd like to bring some attention to ticket #4012 about non-determinism.
>>>> As many of you may know, the nix package manager distributes binaries
>>>> throughout its binary caches. The binaries are shared as long as the
>>>> hash of some of their inputs matches: this means that we can end up with
>>>> two of the same hashes of inputs but thanks to #4012 means that the
>>>> actual contents can differ. You end up with machines with some packages
>>>> built locally and some elsewhere and due to non-determinism, the GHC
>>>> package IDs don't line up and everything is broken.
>>>
>>> is NixOS sensitive to changes in the build directory. Debian is, and
>>> since 7.8 the build path creeps into the interface files and affects the
>>> hash: https://bugs.debian.org/785282
>>>
>>> But you probably are not, otherwise you’d have complained when 7.8 was
>>> out, and not now :-)
>>>
>>> Greetings,
>>> Joachim
>>>
>>
>> Not a problem for nix, the paths are are calculated based on the
>> derivation inputs. I don't want to go into details but if same
>> expression goes in, same path comes out. If the path that comes out is
>> different, you simply don't get to use it. More or less nix does
>> ‘calculate the store path from this expression, check if it exists in
>> binary caches and fetch it if it does, build if it does not’.
>>
>> So for us the store paths in the interface files would always be the
>> same for the same inputs hence no problem there.
>>
>> --
>>

-- 
Mateusz K.