nixVersions.unstable: build from master, re-init at 2.22.0.pre20240321_6fd2f42c

[Ma27]

Description of changes

Things to discuss first:

• Should we use a different attribute, e.g. nixVersions.git? OTOH unstable Nix is already insufficiently stable for nixpkgs, so I'm not sure if that even makes a different currently 🤷
• For that attribute, breaking backports are OK to me. Otherwise, we'll need to remove this from every stable nixpkgs.

---

The idea behind that is to enable users and developers of downstream tools such as home-manager to test Nix master for several reasons:

• Nix is currently trying to have a master branch that's always releasable[1]. We're still on Nix 2.18 in nixpkgs due to too many notable regressions. Enabling people to test latest master may help on that end.

• This uses the most bleeding-edge Nix, but our packaging, so we can identify issues with our packaging early.

• From what I've seen, most people are using the packages from nixpkgs anyways instead of the upstream flake, this is far more convenient anyways.

My plan is to update this once a week. Right now we rely on the installCheckPhase here, but as soon as we have proper regression testing[2], we may want to add nixUnstable there as well (however with failures being allowed probably).

[1] https://discourse.nixos.org/t/nix-release-schedule-and-roadmap/14204
[2] #304332

---

cc @RaitoBezarius @lovesegfault @Artturin
cc @rycee @Enzime (for hm/nix-darwin as downstream projects that might be interested in that).

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[lovesegfault]

I'm AOK with this, I kind of want a latest that's pin to the latest release, but I think it kind of defeats the purpose since most people would use that instead of unstable.

[infinisil]

Should we use a different attribute, e.g. nixVersions.git? OTOH unstable Nix is already insufficiently stable for nixpkgs, so I'm not sure if that even makes a different currently 🤷

I think it should be nixVersions.git, because people already have certain expectations of nixVersions.unstable (it being the latest Nix release) and we shouldn't violate that. Perhaps unstable could be renamed to latest[Release] to make that expectation align more with the name.

For that attribute, breaking backports are OK to me. Otherwise, we'll need to remove this from every stable nixpkgs.

I don't think we need to backport such updates at all. Interested people should use the unstable channel for frequent updates already. There's not much to be gained from backporting this imo.

[Ma27]

because people already have certain expectations of nixVersions.unstable

Given that master claims to be always releasable and we already had quite a bunch of regressions on the last releases, I wasn't sure if that makes that much of a difference. But I see your point.
Personally, I don't mind what it'll end up with, so I made it open for discussion :)

But if a majority of people prefers a change, I'd say we go with nixVersions.git.
I think that we should rename nixVersions.unstable to nixVersions.latest then since it better reflects what it's supposed to be. We'll probably want to add an alias for backwards compat then.
Also, I think a few people may go for git instead of latest when faced with that decisions who might've missed that otherwise.

I don't think we need to backport such updates at all. Interested people should use the unstable channel for frequent updates already. There's not much to be gained from backporting this imo.

There's one thing I don't want to end up with: having a nixVersions.git that's on the same random rev for half a year since that's absolutely useless and costs a build slot regularly (doesn't matter that much probably, but still a waste). Also, I'm sure that someone will end up with that by accident.

So we'll either drop it after every branchoff or backport each change, I'd be fine with both.

[rycee]

Perhaps i would be possible to have a package meta field to indicate that the package is only available in unstable? I.e., something like meta.unstableOnly. If true and when using a non-unstable channel, it could work a bit like broken = true. So it could be left unchanged in the stable branches but attempts to build it would fail with an error message.

In any case, overall I think it is reasonable to have this type of package. Backwards incompatibilities and other similar breakage is very stressful when they are discovered after a release. It so happens to be that I've been working a little on creating some basic integration tests for Home Manager (nix build --option sandbox false -L .#integration-test-all). But it just uses whatever pkgs.nix is in Nixpkgs and these integration tests are currently only run manually.

[Ma27]

Added .git & .latest now.

I.e., something like meta.unstableOnly

Sounds good, but I don't think that this should be an ad-hoc addition here. This looks relevant for every -git variant of a package (e.g. zfs or llvm). For now, I'm inclined to just backport all attributes, including .git.

[Ma27]

Rebased onto latest master, updated Nix to latest master and updated the Perl bindings build for meson support.
For 24.05 I'd just go for backporting that stuff 🤷

Btw, somebody double-checking the perl build would be appreciated.

[Ma27]

Changed the last commit to include a comment explaining why perl-bindings aren't cross-safe. Nothing we can do much about in nixpkgs though.

[Ma27]

Library tests are fine and tested perl-bindings for all nix versions we've packaged. I'd go for it now.

[zowoq]

Unstable was at nix_2_22.

#308434