lib.systems: remove supported, replace with flakeExposed

[sternenseemann]

We don't have hardware for mispel, armv7l nor armv6l for the official
Hydra instance and there are negligibly few i686 jobs.

Description of changes

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• 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/)
• 22.05 Release Notes (or backporting 21.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
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[vcunat]

i686 is unclear to me, as the meaning is unclear to me.

[vcunat]

BTW, is aarch64-darwin really still not on any of these tiers?

[sternenseemann]

i686 is unclear to me, as the meaning is unclear to me.

From the comment I always interpret it as “binary cache is available”. The problem is that this file is basically only used to determine the systems available via the nixpkgs flake which makes this criterium even more bizarre. I think eventually another list “native stdenv available” should be added gating systems in the flake as that would have any useful impact.

BTW, is aarch64-darwin really still not on any of these tiers?

RFC 0046 still lists it as Tier 7 and as I understand it, there would need to be an RFC to promote it. (That would be a formality of course as it is indeed de facto higher already.)

[sternenseemann]

Actually, I think just renaming the hydra attribute to nativeStdenvAvailable makes more sense (as it's the only thing it's actually used for). What do you think?

cc @zimbatm

[zimbatm]

I like your idea. Platform tiers and hydra support aren't entirely relevant.

What matters to the flake is that the platform has enough of a stdenv that the packages might build. Given that the list of systems is not extensible from the outside, it's better to be a bit wider here.

[vcunat]

FYI, we got native stdenv (if I get what you mean) for a new platform recently: #168199

[zimbatm]

yeah, let's track all of those in a nativeStdenv list and then use that for the flake.

[sternenseemann]

yeah, let's track all of those in a nativeStdenv list and then use that for the flake.

Done in 761ba1a. I used pureStdenv to contrast against the “native stdenv” terminology used for e.g. x86_64-freebsd where an impure OS-provided libc would be used. The attribute now lists all platforms for which we have bootstrap-tools.

Edit: In theory we could compute this lists using builtins.readDir, but it's a little finicky for my taste and I do not know if flake eval would like it.

[zimbatm]

Thanks!