​​nixpkgs Merge Queue - Unmaintained Package Removal
​​​+nixpkgs Merge Queue - Overview​ 
​​
​​feature
​​start-date
​​author
​​co-authors
​​shepherd-team
​​shepherd-leader
​​related-issues
​​(fill me in with a unique ident, my_awesome_feature)
​​(fill me in with today's date, YYYY-MM-DD)
​​(name of the main author)
​​(find a buddy later to help out with the RFC)
​​(names, to be nominated and accepted by RFC steering committee)
​​(name to be appointed by RFC steering committee)
​​(will contain links to implementation PRs)
​​
​​
​​
​​
​​
​​
​​
​​
​​THIS DOCUMENT WAS DEEMED UNNECESSARY FOR THE nixpkgs MERGE QUEUE PROJECT AND HAS BEEN INDEFINITELY DEFERRED
​​
​​
​​
​​
​​
​​
​​
​​
​​
​​
​​
​​
​​
​​
​​
​​
​​
​​

​​Summary

​​This formalizes the full procedure removing a package from the nixpkgs​ repo. Including procedure for notifying maintainers, marking unmaintained packages and finally removing the package.

​​Motivation

​​Why are we doing this? What use cases does it support? What is the expected outcome?

​​Prior Discussions

​​
 
We need more defined guidelines for package inclusion
Currently we have many packages that are unmaintained, and part of this problem is that we aren’t setting any metric for what makes something suitable for inclusion in nixpkgs. Other distros like Fedora have guidelines like What can be packaged in Fedora, but I think we’re all aware that NixOS is no where near as strict as other distros when it comes to package inclusion. But I don’t think we’ve documented at least legal reasons when something should be excluded. Personally, I ask the follow...
discourse.nixos.org
We need more defined guidelines for package inclusion • discourse.nixos.org
​​

​​Detailed design

​​This is the core, normative part of the RFC. Explain the design in enough detail for somebody familiar with the ecosystem to understand, and implement. This should get into specifics and corner-cases. Yet, this section should also be terse, avoiding redundancy even at the cost of clarity.

​​Examples and Interactions

​​This section illustrates the detailed design. This section should clarify all confusion the reader has from the previous sections. It is especially important to counterbalance the desired terseness of the detailed design; if you feel your detailed design is rudely short, consider making this section longer instead.

​​Drawbacks

​​Why should we not do this?

​​Alternatives

​​What other designs have been considered? What is the impact of not doing this?

​​Unresolved questions

​​What parts of the design are still TBD or unknowns?

​​Future work

​​What future work, if any, would be implied or impacted by this feature without being directly part of the work?
​​