API surface and deprecation policy

[infinisil]

Issue description

Currently there is no clear nixpkgs policy has regarding stability and deprecation. This was discussed a bit in meeting NixOS/nixpkgs-architecture-issues#12. There is also a NAT wiki article on deprecation.

Previous efforts:

• [RFC 0033] [WIP] Deprecation rfcs#33
• [RFC 0127] Nixpkgs "problem" infrastructure rfcs#127

[Aleksanaa]

I hope we can discuss this again.

The current problem has two aspects: on the one hand, we have no rules for reference to decide when a package can be deprecated or removed; on the other hand, our current handling of deprecation and removal is actually very crude and not automated enough.

The previous discussion of yuzu revealed this: do we really need to immediately remove packages that are obsolete but are still used by a lot of users? Can't we give them time to migrate? On the other hand, such treatment is often only available to popular software, while less popular packages are just lying there, and no one cares about them, even if some of them have been in a state of build failure for a long time.