musl: tighten platforms

[alyssais]

Description of changes

This will make it possible to check whether we can use pkgsStatic opportunistically, in places like busybox-sandbox-shell, which currently decides not to use pkgsStatic based on a hard-coded set of platforms.

I haven't actually changed busybox-sandbox-shell to use it yet, because that would just cause conflicts with #227560, so we can do it later.

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/)
• 23.05 Release Notes (or backporting 22.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.

[wegank]

And I think busybox-sandbox-shell can be changed now?

[alyssais]

And I think busybox-sandbox-shell can be changed now?

In theory, but the check we'd want to use (lib.meta.availableOn stdenv.hostPlatform pkgsStatic.cc.libc) currently produces an error because it fails the meta check before getting to our availableOn call. #213096 would fix it, so I think it's worth waiting for that.

(We don't want to just check for musl there, because pkgsStatic only means musl on Linux.)

[alyssais]

freshBootstrapTools successfully built on riscv64-linux by 0x4a6f (#exotic:nixos.org)

[NickCao]

The change looks reasonable to me, but can we somehow subtract the bad platforms instead of listing the good ones?

[alyssais]

The change looks reasonable to me, but can we somehow subtract the bad platforms instead of listing the good ones?

We can, but I don't think we should. badPlatforms is good when you have a package that is generally portable, but for one reason or another is incompatible with a certain platform. But for stuff like this, where the package needs architecture-specific code for every architecture it supports, it's better to list them explicitly, or we'll end up with false positives any time a new architecture is added to Nixpkgs, and false negatives (when a package is incorrectly marked as being unsupported on a platform) are a lot easier to spot than false positives.