pkgs/top-level/default.nix contains
# Temporary hack to let Nixpkgs forbid internal use of `lib.fileset`
# until <https://github.com/NixOS/nix/issues/11503> is fixed.
__allowFileset ? true,
The issue was fixed 16 months ago. Shouldn’t we remove this “temporary hack”?
IIUC we can’t use filesets in tree until nixpkgs’ minimum supported version of Nix doesn’t have the issue, and IIRC that is not the case.
Realistically, the min version is about the language semantics - not the actual implementation. Nix < 2.28 is unsupported, CI doesn’t check against it and nobody will be actually using it, unless they are willing to actually backport security fixes (some stable fedora might be stuck this way).
Technically, there’s builtins.langVersion if you want to check language semantics. So I would say that builtins.nixVersion is specifically about implementation.
And atm, we assert in nixpkgs that nixVersion is at least “2.18”.
We would need to bump required nixVersion to “2.27”. I guess that requires coordinating with all distros’ nix package maintainers? I don’t know if there’s some place of contact for that? And who can make a decision of bumping minimal nixVersion in nixpkgs?
Or we could just assume that one year is old enough, and just bump it without coordinating with downstreams.
Cough cough lix exists and split off at 2.18. Let’s please not depend on implementation-specific nonsense.
The nixVersion is irrelevant because Lix hardcodes it to 2.18. IMO we can just ignore this, bug has been fixed and the immediate fire has been put out and we can just start using the library – installer tests won’t blow up. All supported nix/lix versions now behave sanely under chroot stores.
Did someone check if lix doesn’t happen to have the same bug?
I ran the reproduction test from the issue on lix 2.94.2 and it doesn’t trigger the issue.
Lix fixed it as well. See the commit.