nixVersions.{nix_2_28,nix_2_26}: switch simplified meson build#393509
nixVersions.{nix_2_28,nix_2_26}: switch simplified meson build#393509Ericson2314 merged 2 commits intoNixOS:masterfrom
Conversation
github-actions
bot
added
10.rebuild-darwin: 1-10
|
|
nix-owners
bot
requested review from
Ericson2314,
RaitoBezarius,
edolstra,
roberth and
tomberek
Mic92
changed the title
|
Keeping this as plan b in case we have other issues with the current packaging. Deployed on my machines like this. |
|
Hey, I want to give my feedback -- as someone who runs NixOS and wants to use the released-three-days-ago Nix 2.27.1 -- that I really support a simple and straightforward derivation like this one over the vendored code from the Nix repository. Inside the Nix repository, it makes sense! There's lots of value in articulating the build dependency graph between components and enabling minimal rebuild, among other things. Here in Nixpkgs, I see a lot of value in thinking of Nix primarily as a unitary product... and of thinking of these components ( As I wrote on the Nix Package Manager development Matrix channel, all that code was checked in under I support merging a version of this just on the grounds that it makes updating Nix in Nixpkgs better. |
|
I did not communicate the intent behind the new packaging. The point was for this to support RFC 134, so if we merge this we'll have to get back to that, perhaps without the vendoring. |
Okay, could you write down some guide what needs to be done to update nix in nixpkgs (there is already a README in their)? |
|
It should be otherwise also support to implement https://github.com/NixOS/rfcs/blob/master/rfcs/0134-nix-store-layer.md with just a monolithic build using multiple outputs. |
|
Since other Nixpkgs maintainers are critical of the vendoring approach, we could just drop the
Unless I forgot something, that will make it a completely normal Nixpkgs package set. That gives us no path to make syncing exprs easier, but so be it. Short of things like disabling the AWS dep, the exprs should be quite stable by now. If we don't do this, alternative solutions:
I believe this would cover most of the "weirdness" (my phrasing). |
ofborg
bot
removed
the
2.status: merge conflict
So we are adding a simplified version that builds a monolithic nix binary to get finished in time for the release. Afterwards we will switch to the modular build again.
|
@Ericson2314 You missed the removal of |
|
oops, yes I did. |
Introduced in - NixOS#393509 - and NixOS#396773
|
|
The `hash` and `self_attribute_name` values have been copied from `nix_2_28` in #393509
| ] | ||
| ++ lib.optionals stdenv.hostPlatform.isLinux [ | ||
| (lib.mesonOption "libstore:sandbox-shell" "${busybox-sandbox-shell}/bin/busybox") | ||
| # RISC-V support in progress https://github.com/seccomp/libseccomp/pull/50 |
There was a problem hiding this comment.
There is nothing to be done except for dropping the comment as far as I can tell.
10 participants
The current componentized build still has some issues, so we are adding a simplified version that builds a monolithic nix binary to get finished in time for the release.
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.