Each bootstrapping stage ought to just depend on the previous stage, but
poorly-written compilers break this elegence. This provides an easy-enough
way to depend on the next stage: targetPackages. PLEASE DO NOT USE IT
UNLESS YOU MUST!
I'm hoping someday in a pleasant future I can revert this commit :)
* Update python.md
this makes it clear how to alter `attributes` by using `packageOverrides`
* Update python.md
* Update python.md
* Update python.md
* Update python.md
* Update python.md
* Update python.md
Fix code syntax highlighting by specifying language in every code block
and adding some context to Nix code blocks to make them valid
expressions. Use the same markup style for all code blocks. Reformat
some code blocks.
fixes#23535
- Describe the new `libsForQt5.callPackage` interface
- Emphasize that Qt dependencies must be imported unqualified
- Describe the new `kdeWrapper` wrapper generator
If a package's meta has `knownVulnerabilities`, like so:
stdenv.mkDerivation {
name = "foobar-1.2.3";
...
meta.knownVulnerabilities = [
"CVE-0000-00000: remote code execution"
"CVE-0000-00001: local privilege escalation"
];
}
and a user attempts to install the package, they will be greeted with
a warning indicating that maybe they don't want to install it:
error: Package ‘foobar-1.2.3’ in ‘...default.nix:20’ is marked as insecure, refusing to evaluate.
Known issues:
- CVE-0000-00000: remote code execution
- CVE-0000-00001: local privilege escalation
You can install it anyway by whitelisting this package, using the
following methods:
a) for `nixos-rebuild` you can add ‘foobar-1.2.3’ to
`nixpkgs.config.permittedInsecurePackages` in the configuration.nix,
like so:
{
nixpkgs.config.permittedInsecurePackages = [
"foobar-1.2.3"
];
}
b) For `nix-env`, `nix-build`, `nix-shell` or any other Nix command you can add
‘foobar-1.2.3’ to `permittedInsecurePackages` in
~/.config/nixpkgs/config.nix, like so:
{
permittedInsecurePackages = [
"foobar-1.2.3"
];
}
Adding either of these configurations will permit this specific
version to be installed. A third option also exists:
NIXPKGS_ALLOW_INSECURE=1 nix-build ...
though I specifically avoided having a global file-based toggle to
disable this check. This way, users don't disable it once in order to
get a single package, and then don't realize future packages are
insecure.
This fixes the "sliding window" principle:
0. Run packages: build = native; host = foreign; target = foreign;
1. Build packages: build = native; host = native; target = foreign;
2. Vanilla packages: build = native; host = native; target = native;
3. Vanilla packages: build = native; host = native; target = native;
n+3. ...
Each stage's build dependencies are resolved against the previous stage,
and the "foreigns" are shifted accordingly. Vanilla packages alone are
built against themsevles, since there are no more "foreign"s to shift away.
Before, build packages' build dependencies were resolved against
themselves:
0. Run packages: build = native; host = foreign; target = foreign;
1. Build packages: build = native; host = native; target = foreign;
2. Build packages: build = native; host = native; target = foreign;
n+2. ...
This is wrong because that principle is violated by the target
platform staying foreign.
This will change the hashes of many build packages and run packages, but
that is OK. This is an unavoidable cost of fixing cross compiling.
The cross compilation docs have been updated to reflect this fix.
If the flag enableIntegerSimple is true GHC will be build with the GPL-free but
slower integer-simple library instead of the faster but GPLed integer-gmp
library.
The attribute `pkgs.haskell.compiler.integer-simple."${ghcVersion}"` provides a
GHC compiler build with `integer-simple`.
Similarly, the attribute `pkgs.haskell.packages.integer-simple."${ghcVersion}"`
provides a package set supporting `integer-simple`.
Closes https://github.com/NixOS/nixpkgs/pull/22121.
Closes https://github.com/NixOS/nixpkgs/issues/5493.
The Nix search path is the established mechanism for specifying the
location of Nix expressions, so let's use it instead of adding another
environment variable.
Do so in the stdenv section where the other two are discussed. This can be
done without brining up cross-compilation by talking about build-time vs
run-time.
