The text was originally added [0] following an apparently incomplete
research on how everything plays together. In fact, Nix propagates
`outputs` to the corresponding nested derivations, and there is some
messy behavior in Nixpkgs that only seems to propagate
`meta.outputsToInstall` in `buildEnv`[1].
This change moves the hints on how to use NixOS specifics to NixOS
module documentation (which is hopefully easier to find through
search.nixos.org), describes the default behavior in Nixpkgs (updating
a the link to the source), and removes the confusing mention of
`nix-env`.
the last of them should not be there to begin with. we don't want
beginners to use `nix-env`, as this is known to run them into trouble
eventually.
[0]: https://github.com/NixOS/nixpkgs/pull/76794
[1]: 1774d07242/pkgs/build-support/buildenv/default.nix (L66)
* Updates meta.chapter.md with a reference link to the usage of the package description field instead of referring to nix-env
---------
Co-authored-by: Valentin Gagarin <valentin.gagarin@tweag.io>
Clarify that the monochrome font is not included, per #221181.
The new name is also coherent with the name of the font,
according to `fontconfig`: Noto Color Emoji.
This change which involves creating multiple outputs for CUDA
redistributable packages.
We use a script to find out, ahead of time, the outputs each redist
package provides. From that, we are able to create multiple outputs for
supported redist packages, allowing users to specify exactly which
components they require.
Beyond the script which finds outputs ahead of time, there is some custom
code involved in making this happen. For example, the way Nixpkgs
typically handles multiple outputs involves making `dev` the default
output when available, and adding `out` to `dev`'s
`propagatedBuildInputs`.
Instead, we make each output independent of the others. If a user wants
only to include the headers found in a redist package, they can do so by
choosing the `dev` output. If they want to include dynamic libraries,
they can do so by specifying the `lib` output, or `static` for static
libraries.
To avoid breakages, we continue to provide the `out` output, which
becomes the union of all other outputs, effectively making the split
outputs opt-in.
