When maintainers override stages of `fetchgit' (e.g. `postPatch`) it
is very easy for them to accidentally leak the outpath-hash of their
current `stdenv` into `fetchgit''s output, and therefore into the
value they paste into `sha256`.
This is a problem, because the resulting expression will break
whenever any change is made to `stdenv` or when anybody attempts to
build the expression on a different platform than the one used by the
original maintainer.
Almost as much of a problem is the fact that CI **does not catch**
these problems. The `fetchgit` is run only once, then its output goes
into cachix, and all future builds (hydra, CI, ofborg) pull from
cachix.
Let's offer maintainers the option to check that they aren't making
this mistake, by passing through `allowedRequisites`. The default
value is `null`, but it might be worth changing that at some point in
the future.
It is also sometimes difficult to communicate to package maintainers
why their expression is problematic. Having `allowedRequisites`
passed through makes it easier to do this: "look, when I switch on
`allowedRequisites` your package breaks; are you sure you meant to
hardcode the hash today's `x86_64-linux.stdenv` into your expression?`
For an example use case, see https://github.com/NixOS/nixpkgs/pull/171223
The issue above is part of a larger problem with nixpkgs infra: there
large parts of cachix cannot be reproduced easily if they are lost.
Once something ends goes into cachix, we never ever again reverify the
procedure by which it was placed into cachix.
5ed4944130