make-derivation.nix: warn that meta.available is deprecated

[ghost]

Description of changes

Deprecate meta.available and recommend lib.meta.availableOn stdenv.hostPlatform instead.

meta.available is affected by impure environment variables like NIXPKGS_ALLOW_NONSOURCE. It's okay for environment variables like that to cause a build to fail, but if we start switching dependencies in and out based on meta.available we can get builds that succeed differently when you flip those on.

This actually happened to me shortly after I started using allowNonSource=false, and it was a total nightmare to debug: #179648

Despite the similar-sounding name, lib.meta.availableOn doesn't have this problem. It is unaffected by impure environment variables and config.allowXYZ preferences. It only checks meta.{platforms,badPlatforms}.

#227120 (comment)

Also adds three commits which change the (only) three uses of meta.available in nixpkgs to use lib.meta.availableOn instead.

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.

[sternenseemann]

Can you figure out why ofborg and Hydra evaluate meta.available? My intuition would be that this should not be evaluated normally, so the inOfBorg hack would not be necessary?

I think this change is best to have in after branch-off to give downstream and us a bit of time to deal with any unforeseen consequences. A changelog entry is also a good idea.

[ghost]

Can you figure out why ofborg and Hydra evaluate meta.available?

I think it's this line in hydraJob:

nixpkgs/lib/customisation.nix

Line 263 in b75b059

lib.deepSeq drv' drv';

Another alternative that I came up with after writing this would be for checkMeta to abort instead of throw when it encounters something forbidden by NIXPKGS_ALLOW_*. This ensures that NIXPKGS_ALLOW_* can prevent eval from succeeding but can't affect the result of a successful eval (because you can't "catch" an abort using tryEval).

[ghost]

this change is best to have in after branch-off

Yes definitely. This is a candidate for the "okay to break stuff" window right after the release.

[sternenseemann]

As far as I can tell, hydra-eval-jobs never looks at meta.available, so it should be possible to builtins.removeAttrs meta [ "available" ] in hydraJob to circumvent this problem.