The parent commit forbids conflicting kernel config options.
Fix the hardened kernels by allowing options in common-config.nix to
be overridden by conflicting ones in hardened/config.nix.
I'm explicitly avoiding using a higher priority (e.g. using mkForce)
in hardened/config.nix so that the user can easily override the
options in that file.
Previously, cabal-install had a custom Setup.hs which took care of
generating and installing the cabal(1) man page. While this file was a
bit of scary sight, it is certainly nice to have a man page properly
installed. For the 3.2.0.0 release they switched to the default setup
type again, so the man page isn't installed anymore. Fortunately the
cabal cli can generate the man page as well, so the override to add the
man page back is pretty simple.
The commit that introduced this is the following:
91ac075930
I actually made a mental note of this a few weeks ago already, but it
slipped my mind when we updated to cabal-install 3.2.0.0 two weeks ago
unfortunately.
Currently, kernel config options whose value is "yes" always override
options whose value is "no".
This is not always desired.
Generally speaking, if someone defines an option to have the value
"no", presumably they are disabling the option for a reason, so it's
not always OK to silently enable it due to another, probably unrelated
reason.
For example, a user may want to reduce the kernel attack surface and
therefore may want to disable features that are being enabled in
common-config.nix.
In fact, common-config.nix was already silently enabling options that
were intended to be disabled in hardened/config.nix for security
reasons, such as INET_DIAG.
By eliminating the custom merge function, these config options will
now use the default module option merge functions which make sure
that all options with the highest priority have the same value.
A user that wishes to override an option defined in common-config.nix
can currently use mkForce or mkOverride to do so, e.g.:
BINFMT_MISC = mkForce (option no);
That said, this is not going to be necessary in the future, because
the plan is for kernel config options defined in nixpkgs to use a
lower priority by default, like it currently happens for other module
options.
