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 <s...@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.du...@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@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > > > _______________________________________________ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev >
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev