New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
sandbox
innix.conf
on non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
./result/bin/
)nix path-info -S
before and after)