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

[Alexander Kjeldaas]

I don't like to use the git hash, as it is SHA1 and not fit for use wrt
integrity.  I think that would be a regression wrt the complex tricks that
Georges referred to.

Would it be possible to create a git wrapper that does the
make_deterministic_repo step in a transparent manner for cargo and have
this git be in the build environment?

Alexander

On Fri, Jan 2, 2015 at 9:07 PM, Wout Mertens <wout.mertens at gmail.com> wrote:

> 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
>>
>
> _______________________________________________
> 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/20150104/e173e5da/attachment.html