Putting information in external JSON files is IMHO not an improvement
over the idiomatic style of Nix expressions. The use of JSON doesn't
add anything over Nix expressions (in fact it removes expressive
power). And scattering package info over lots of little files makes
packages less readable over having the info in one file.
Deprecation warnings should not be used in Nixpkgs because they spam
innocent "nix-env -qa" users with (in this case) dozens of messages
that they can't do anything about.
This also reverts commit 2ca8833383.
This makes it easy to specify kernel patches:
boot.kernelPatches = [ pkgs.kernelPatches.ubuntu_fan_4_4 ];
To make the `boot.kernelPatches` option possible, this also makes it
easy to extend and/or modify the kernel packages within a linuxPackages
set. For example:
pkgs.linuxPackages.extend (self: super: {
kernel = super.kernel.override {
kernelPatches = super.kernel.kernelPatches ++ [
pkgs.kernelPatches.ubuntu_fan_4_4
];
};
});
Closes #15095
These functions used to live in pkgs/development/haskell-modules/default.nix,
but they are generic, really, and should be easily accessible to everyone.
This is primarily useful in Nix expressions that are also intended to
be used by nix-shell. It allows saying things like:
buildInputs = [ ... ] ++ (if inNixShell then [ emacs ] else [ ]);
This should not be used in Nixpkgs (since the question of what
constitutes a useful nix-shell environment is very subjective).
This makes it a bit easier to find out the current Nixpkgs version,
e.g.
$ nix-instantiate --eval '<nixpkgs>' -A lib.nixpkgsVersion
"14.02.35657.66f51a9"
