-
-
Notifications
You must be signed in to change notification settings - Fork 158
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[RFC 0180] Remove broken and unmaintained leaf packages
- Loading branch information
Showing
1 changed file
with
87 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,87 @@ | ||
--- | ||
feature: broken-package-removal | ||
start-date: 2024-07-14 | ||
author: Jörg "Mic92" Thalheim | ||
co-authors: | ||
shepherd-team: | ||
shepherd-leader: | ||
related-issues: | ||
--- | ||
|
||
# Summary | ||
|
||
[summary]: #summary | ||
|
||
This RFCs defines under what conditions we remove broken and unmaintained leaf packages. | ||
The RFC does not have the ambition to define all reasons to remove a package but | ||
instead focuses on simple rules that can be automated. | ||
|
||
# Motivation | ||
|
||
[motivation]: #motivation | ||
|
||
Broken and unmaintained packages still cost us valuable time. | ||
Broken packages still have to be evaluated to some extend | ||
and unmaintained packages might still have to rebuild when one of their dependencies changes. | ||
Removing unmaintained/unused code hopefully increases the overall package quality and helps us | ||
to save resources. | ||
Because it is easy to add packages, it should be also easy to remove them, ideally automated. | ||
|
||
# Detailed design | ||
|
||
[design]: #detailed-design | ||
|
||
## Broken Packages | ||
|
||
Packages that are marked as broken unconditionally platforms should be removed after one full NixOS release cycle. | ||
If the package had dependencies, those dependencies are also marked as indirectly broken. | ||
If they are not functional without the broken package, they should be removed as well. | ||
|
||
## Unmaintained packages | ||
|
||
Packages with an empty maintainer field that does not have packages depending on it, should | ||
be removed after 2 months. Ideally we have an automation or semi-automation that creates pull requests for that. | ||
|
||
If a NixOS module depends on any of removed package, this module gets removed as well, if it is non-functional without the package. | ||
In `pkgs/top-level/aliases.nix` we can link to the pull request that removed the package, | ||
to make it easier for people to recover the nix expression. | ||
|
||
# Examples and Interactions | ||
|
||
[examples-and-interactions]: #examples-and-interactions | ||
|
||
- | ||
|
||
# Drawbacks | ||
|
||
[drawbacks]: #drawbacks | ||
|
||
Some maintained packages might still have users that won't be able to use the package, | ||
but the hope is that the removal of unmaintained package will lead to these people | ||
stepping up as a maintainer. Recovering from the git history should be easy in that case. | ||
|
||
# Alternatives | ||
|
||
[alternatives]: #alternatives | ||
|
||
Keep all packages. | ||
|
||
# Prior art | ||
|
||
[prior-art]: #prior-art | ||
|
||
- Most Linux distributions have rules around removing unmaintained packages i.e. Debian. | ||
- [Nixpkgs eval time is increasing too fast](https://github.com/NixOS/nixpkgs/issues/320528): | ||
This issue discusses how we can improve the evaluation time. | ||
|
||
# Unresolved questions | ||
|
||
[unresolved]: #unresolved-questions | ||
|
||
? | ||
|
||
# Future work | ||
|
||
[future]: #future-work | ||
|
||
? |