I believe this change is wrong both theoretically and practically.
Theoretically, `null` is available on every platform, because
`buildInputs = [ null ];` always succeeds and never throws a platform
availability error. `null` should be handled consistently with packages
that have no explicit list of supported platforms, as it of course
has no such list itself.
Practically, we use `null` to represent libraries that are always
present on a platform and do not require a library (for instance,
because they are part of `libc` or the macOS SDK). This has been
used for a long time by `libintl` (on all non‐glibc platforms),
and is also now used by `libGL` and friends on Darwin. This change
broke the check SDL3 does for OpenGL availability on Darwin, causing
<https://github.com/NixOS/nixpkgs/issues/407056>, which had to be
worked around by <https://github.com/NixOS/nixpkgs/pull/409525>.
Both `libintl` and `libGL` should count as available on platforms
where their functionality is part of the standard build environment,
and a package that is completely unavailable and whose functionality
cannot be expected should not use `null`, as it should result in
errors if used in a dependency list on an unsupported platform.
I accept that overriding with `null` is often a useful way to disable
dependencies that don’t have explicit feature flags, but I do not
think that making it work better with feature flags conditioned on
availability is worth the inconsistency and problems caused by this
change. Packages can instead expose the relevant feature flags as
arguments that default to the `lib.meta.availableOn` check or, if they
want to keep an “override the dependency to `null`” interface,
insert an explicit `pkg != null && …` check.
Additionally, the pull request was merged over a week after all
breaking changes were restricted for the 25.05 release. I believe that
the potential problems of dealing with the effects of this change for
an entire release cycle – the first release cycle where `libGL` is
`null` on Darwin, a change I made before the deadline and before this
change to `lib.meta.availableOn` – offset the risks of backporting
this revert at such a late stage.
It will cause overrides to backwards‐incompatibly revert to the
behaviour they had before the change, but since such overrides were
not possible until a few weeks ago, I hope that is an acceptable risk
compared to the potential issues leaving this in the release can
cause, given that it was merged after the deadline and has already
broken an existing construction in Nixpkgs.
This reverts commit 9338d924db.
R. Ryantm