check-meta: add allowBrokenPredicate

[amarshall]

Similar to allowUnfreePredicate, sometimes users may want to only allow specific broken packages to avoid unexpectedly building others.

Some packages may be marked broken for policy reasons (lack of upstream support) or due to broken or unsupported functionality that the user may not care about. An example might be forcing ZFS to build on a newer, unsupported Kernel where compilation succeeds and the user is willing to take the risk of being unsupported.

I think the larger topic for discussion would be: should broken be used in this way? I.e., should broken only be used for packages that actually fail to build or fundamentally work at all, or is it okay to use it for things that might work but are explicitly unsupported? The manual for broken doesn’t say much about when to use it.

If the answer is that broken should only be used for things that fail to build or fundamentally work, then perhaps this PR doesn’t make sense as there’s little use-case for bypassing broken on a per-package basis in one’s config. It does bring up the question, though: how should we then mark packages whose config is unsupported? Back to the ZFS example, running a filesystem on Kernels not explicitly tested and supported by upstream seems like a bad idea by default, and users should have to opt-in to that risk in some way.

Description of changes

Things done

Tested with

$ nix-build -A linuxKernel.packages.linux_testing.zfs_unstable
…error: Package ‘zfs-kernel-2.2.5-6.11-rc6’ … is marked as broken, refusing to evaluate.…

$ < config.nix echo '{ pkgs }: { allowBrokenPredicate = pkg: pkgs.lib.hasInfix "zfs" pkg.pname; }'
$ NIXPKGS_CONFIG=$(pwd)/config.nix nix-build -A linuxKernel.packages.linux_testing.zfs_unstable
…building…

• 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.11 Release Notes (or backporting 23.11 and 24.05 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.

[adamcstephens]

Sounds good to me, but this should get much wider comment before merging.