nixos/kernel.nix: ensure same kernel is used#87856
Conversation
|
I can't tell if this is doing the right thing because I get confused with the overriding mechanisms. |
|
Would it be possible to |
6e2f31b to
86456e8
Compare
|
Yeah a better fix would probably be fixing the |
86456e8 to
12acc62
Compare
12acc62 to
a32c412
Compare
a32c412 to
d8c32c3
Compare
d8c32c3 to
ce5eec9
Compare
ce5eec9 to
33aaae5
Compare
33aaae5 to
a34f5a3
Compare
a34f5a3 to
9b3dea9
Compare
9b3dea9 to
0d274c3
Compare
Originally, changes to the kernel don't propagate to the other derivation within the same package set. This commit allows for the changes in the kernel to be propagated. A distinct example is setting `boot.kernel.randstructSeed` to a non-zero length string which would result in building 2 kernels, one with the correct seed and the other with the zero length seed. Then, when using an out-of-tree kernel driver, it would be built with the zero length seed which differs from the non-zero length seed used to boot, contradicting the purpose of the `boot.kernel.randstructSeed`.
0d274c3 to
78f915a
Compare
There was a problem hiding this comment.
The careless use of super is a common antipattern that you also see a lot in user overlays on the internet. If in an overlay you do
self: super: {
foobar = super.stdenv.mkDerviaton { ... };
}this will prevent the user from overriding stdenv for that derivation and it's no longer possible to, e.g. build foobar with a different C compiler. Overrides are simpler and don't have this problem. They compose and you can even do things like this
((nixos-shell.override { nix = nixFlakes; }).override { nix = nixStable; }).override { nix = nixUnstable; }That's exactly what this PR proposes and therefore I approve!
|
This significantly changes the semantics of the See #111845 for a fix for the original problem with |
Motivation for this change
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)