nixVersions.nix_2_26: fix cross#392832
Conversation
There was a problem hiding this comment.
Exposing the components as a first-class scope is required for cross compilation.
|
Backport failed for Please cherry-pick the changes locally and resolve any conflicts. git fetch origin release-24.11
git worktree add -d .worktree/backport-392832-to-release-24.11 origin/release-24.11
cd .worktree/backport-392832-to-release-24.11
git switch --create backport-392832-to-release-24.11
git cherry-pick -x c0df86f0ab7460fd64f5789f1b92d189eb16305d e9494dd2232526279f6229d3f1ce3b6da1609cb3 ac543ea035a0d6b3b8dc5187d82a04fc06c78d20 |
|
This broke eval. Reverting for now. |
|
Can we please just have a simple derivation for 2.26 that works rather than trying to vendor a bunch of code from the Nix flake that keeps causing packaging issues…? I don’t know if we want to ship 25.05 with |
|
I guess the test failure came from
IMO that is not a totally fair way to look at this. We've been writing the code with the goal of including things in Nixpkgs the whole time --- it's not a "flake first" design at all. We're going from a single "big chungus" package to a package set. Sketchy free-floating overrides like the above are bound to cause problems. The vast majority of the code changing here is from formatting, too. |
|
It really doesn’t feel like idiomatic Nixpkgs code to me, even for a large package set. There’s parts of the packaging that look load‐bearing but are pure dead code in Nixpkgs, and I think the complexity of But I’m more concerned about the fact that the freeze is on the horizon and stuff is still broken because of it. The package wasn’t split up prior to 2.26, and I think splitting it up currently doesn’t give a practical benefit, so having a working |
|
(And even if the override is sketchy, we probably should not change the public flag API of a package as central as Nix without a deprecation cycle or at least an explicit error message.) |
IMO there are huge practical benefits, and I wrote an RFC about better layering to spell them out, but it takes a while for these things to bake. For example, we wouldn't need any
The "nix everything" was supposed to be the compat shim. IMO once we're fully transitioned over, nothing should be using it.
I would like to do that. We're pioneering a lot of stuff, including file sets, so there are a lot of idioms to be shaken out.
Yeah, that is the frustrating part. It's been 6 months since we "just" delayed Meson for 24.11, and somehow it still feels like we are running out out of time. |
Getting rid of one alias doesn't seem a good enough reasons to have this much complexity in nixpkgs.
I am voting for a simpler meson package until this transition is actually being finished.
I also feel like I no longer have a good overview what differences between the nixpkgs and the nix repo is. There subtle different. |
This was done in NixOS#392832, but then that was reverted. Want to land the formatting right away before making the next version we hopefully don't need to revert.
This contains a formatting commit, so best to review the commits individually.
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.