Sometimes I want to pass a different implementation of `mkNugetDeps`.
For example in private repos, it can be handy to use `__noChroot = true`
and bypass the deps.nix generation altogether. Or some Nuget packages
ship with ELF binaries that need to be patched, and that's best done as
soon as possible.
If the package was not restored from nuget.org (determinted by checking
the "source" field of ".nupkg.metadata"), query the custom source for
the package endpoint (the way nuget api is built we can't determine it
without an API query) and build a custom package URL to save in the
generated deps file.
With Rust 1.61, it is necessary to link to external static/dynamic libaries
when building the rlib that uses them, rather than when linking the final
binary. In fact, it is no longer necessary to specify the libraries to link
when building the final binary, but the library search path flags must still
be included.
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.
Otherwise, these warnings are emitted:
command-line option '-Wformat=1' is valid for C/C++/ObjC/ObjC++ but not for Fortran
command-line option '-Wformat-security' is valid for C/C++/ObjC/ObjC++ but not for Fortran
'-Werror=' argument '-Werror=format-security' is not valid for Fortran
Fixes part of #27218
- put `findlib` in `buildInputs` of `mkCoqDerivation` to make sure `coq` packages find their ocaml plugin dependencies,
- use `propagatedBuildInputs` to make sure ocaml plugin dependencies are in path,
- updated `coqPackage.heq` (broken url),
- fixed use of `DESTDIR` and `COQMF_COQLIB` in mkCoqDerivation,
- adding `COQCORELIB` environement variable to put ocaml plugin files in the right place,
- make `metaFetch` available from `coqPackages`
