Description
stdenv/generic/check.meta consists of several kinds of "refusing to overlay" checks, messages, and remediation mechanisms, ranging from unsupported or unfree packages to broken or maintainer-less packages. However, no consistent way exists to determine whether a package has been meta-rejected (not even builtins.tryEval).
In addition, we have a user-defined rejection meta.broken, but it doesn't allow developers to specify the reason for the breakage/constraint, potentially leading to the hacky disabled pattern implemented with lib.extendDerivation being adopted by language-specific build helpers such as buildPythonPackage. lib.extendDerivation is low-level and is known to break the functionality of existing overriders of a package, including overrideAttrs, making it hard to get rid of custom overriders (such as overridePythonAttrs) and their maintenance overhead.
The following enhancement would help solve the issues:
- A unified way to determine whether and how a package is meta-rejected.
- An interface to show custom reasons for meta-rejection.
- Reasonable overriding capability of the meta-rejection switches.
(I tried to write a Nix RFC for this but was not competent enough to tackle such infrastructural design.)