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 <fuuze...@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. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs