top-level, lib: Remove platform attribute of platforms#110544
top-level, lib: Remove platform attribute of platforms#110544Ericson2314 merged 2 commits intoNixOS:masterfrom
Conversation
89edaa3 to
363d1f8
Compare
363d1f8 to
769e9ec
Compare
This is now possible, since the `platform` attribute has been removed in PR NixOS#107214. I've been waiting to do a cleanup like this for a long time!
769e9ec to
2dde589
Compare
|
I think this broke the tarball build on darwin which is blocking unstable |
|
I'll investigate. |
This was not working after #110544 as caught by @r-burns in #110544 (comment). Thankfully it isn't used anymore and I believe wasn't documented either. (I at least did not remember it existed.)
|
|
||
| system.build.installBootLoader = builder; | ||
| system.boot.loader.id = "raspberrypi"; | ||
| system.boot.loader.kernelFile = platform.kernelTarget; |
There was a problem hiding this comment.
linux-kernel does not exist in this scope. platform comes from inherit (pkgs.stdenv.hostPlatform) platform; and is now unused.
This does not evaluate.
There was a problem hiding this comment.
Sorry, I will fix. How should I test this?
There was a problem hiding this comment.
Good question. nix-build -E '(import ./. {}).nixos { boot.loader.raspberryPi.enable = true; boot.loader.grub.enable = false; fileSystems."/".device = "e"; }' should work.
Thanks @ajs124 in #110544 (comment) for catching this. According to: git grep 'inherit.*Platform.*platform' git grep ' linux-kernel' We now don't have any remaining problems of this sort, thankfully.
|
Were those values intended to be entirely internal to Nixpkgs? Should a compatibility shim be put in place to prevent external breakage? Right now, I'm in a situation where I cannot just push the fix to Mobile NixOS because there are other breakage with cross-compilation that needs to be addressed. Applying the patch means I need an out-of-tree workaround to work with a known-good Nixpkgs. Not applying it means Hydra can't show the progress with regards to regressions. As a broader topic, not really fit for here, what's the expected stability of Nixpkgs APIs? Should things just disappear like that? Should there always be a transition period where both are possible? Sorry, I don't want to only rant here. I know the change is entirely made with good intentions in mind, and with Nixpkgs in mind. I want to get the ball rolling about thinking how to make all the platform things less problematic to use external to Nixpkgs. I think there were other changes with 20.09->21.05, that'll bite a few individuals who stick to stable I'm sure. These kind of breakage also make bisecting across different repos a bit more cumbersome. |
Deals with NixOS/nixpkgs#110544 This is a breaking change; the kernel builder cannot be used with a Nixpkgs from before this change, and vice-versa.
Deals with NixOS/nixpkgs#110544 This is a breaking change; the kernel builder cannot be used with a Nixpkgs from before this change, and vice-versa.
Motivation for this change
First commit: take II of #107214 which for some reason became a mass rebuild.
Second commit: Simplify top level.
Things done
sandboxinnix.confon non-NixOS linux)nix-shell -p nixpkgs-review --run "nixpkgs-review wip"./result/bin/)nix path-info -Sbefore and after)