[Nix-dev] Request for comments: pinky-promise determinism

[Wout Mertens]

Another use-case: providing the same input hash, based only on version, for
gcc and cross-gcc on another platform. Ditto for ccache and distcc.

On Fri, Jan 2, 2015, 14:56 Shea Levy <shea at shealevy.com> wrote:

> For dirty dirty hacks, you can set __noChroot = true and get access to the
> network.
>
> On Jan 2, 2015, at 1:09 PM, Georges Dubus <georges.dubus at gmail.com> wrote:
>
> Hello everyone
>
> I would like to propose compromise in the purity rules of non-fixed-output
> derivations, and hear what you think about it.
>
> # Rationale
>
> There are a few situations where derivations play the role of fixed-output
> derivation, but the hash of their output is not fixed. Some examples:
> - fetchgit derivations when the .git must be kept. The .git directory is
> incredibly hard to make deterministic, as this require tweaking with
> implementation details: purging any commit that might have been downloaded
> from the server, that may have no link with the reference we are using.
> - cargo, the package manager for the rust language, uses git to download
> its database, and to check it is up-to-date. The same problem as with
> fetchgit arise, with the increased trouble that we are now tweaking the
> implementation detail of an implementation detail.
>
> However, we can trust that, even though the .git is not binary identical
> in each situation, the result of the git commands we could use in the
> packaging task is always the same.
>
> # Proposition
>
> I propose a new kind of derivation that would be identical to the current
> non-fixed-output derivation, but without any restriction on its access to
> the outside world.
>
> The documentation should state that this kind of derivation is dangerous,
> and should only be used when a trustworthy tool is used (since the tool is
> trusted to be deterministic in its behaviour).
>
> This new derivation could be used for dirty hacks, but this should be
> discouraged by the documentation, and never accepted inside nixpkgs.
>
> # Conclusion
>
> The inclusion of this new kind of derivation would allow a satisfying
> implementation of leaveDotGit for fetchgit, one that does not rely on
> complex tricks[1], and allow me to implement cargo support without relying
> on non-future-proof internals tweaking.
>
> However, this would be at the cost of including a new kind of derivation
> that is much less satisfying, and that could, if misused, come back to bite
> us.
>
>
> I'd love to hear what you think about it.
>
>
> [1]
> https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/fetchgit/nix-prefetch-git#L198
>
>
> --
> Georges Dubus
>  _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20150102/d7b16e63/attachment.html