Peter Simons wrote:
> If we're using the model where derivations are defined to produce a
> set of possible results that are functionally equivalent (because we
> can't always force everything about the build process to be
> deterministic in result-bytes), then it doesn't necessarily make
> sense to say "doesn't change the hash" rather than "doesn't make the
> behavior vary any more than it does between compiles without any
> build-modifications"?
I am sorry, but I don't understand the meaning of this paragraph. Can
you please re-iterate this point?
oh, sorry. My understanding was that derivations are already not all
deterministic. That is, (for some packages), given the same source code
and builder, the build process might produce one output (hash) one day
and a different one the next time you try it.
If that understanding is true, then it's not necessarily clear what the
meaning is of a statement that a modification such as NUM_CORES "doesn't
change the hash". -- because "the hash" wasn't even well-defined before
the addition of NUM_CORES.
This is based on the discussion of "equivalence classes" in
dolstra-thesis.pdf, section 6.4 "Semantics". ( which I apparently
downloaded from http://grosskurth.ca/bib/2006/dolstra-thesis.pdf ). I'm
not sure how valid its pessimism about determinism is in most cases though.
-Isaac
_______________________________________________
nix-dev mailing list
[email protected]
https://mail.cs.uu.nl/mailman/listinfo/nix-dev
