|
| 1 | +--- |
| 2 | +feature: broken-package-removal |
| 3 | +start-date: 2024-07-14 |
| 4 | +author: Jörg "Mic92" Thalheim |
| 5 | +co-authors: |
| 6 | +shepherd-team: |
| 7 | +shepherd-leader: |
| 8 | +related-issues: |
| 9 | +--- |
| 10 | + |
| 11 | +# Summary |
| 12 | + |
| 13 | +[summary]: #summary |
| 14 | + |
| 15 | +This RFCs defines under what conditions we remove broken and unmaintained leaf packages. |
| 16 | +The RFC does not have the ambition to define all reasons to remove a package but |
| 17 | +instead focuses on simple rules that can be automated. |
| 18 | + |
| 19 | +# Motivation |
| 20 | + |
| 21 | +[motivation]: #motivation |
| 22 | + |
| 23 | +Broken and unmaintained packages still cost us valuable time. |
| 24 | +Broken packages still have to be evaluated to some extent |
| 25 | +and unmaintained packages might still have to rebuild when one of their dependencies changes. |
| 26 | +Removing unmaintained/unused code hopefully increases the overall package quality and helps us |
| 27 | +to save resources. |
| 28 | +Because it is easy to add packages, it should be also easy to remove them, ideally automated. |
| 29 | + |
| 30 | +# Detailed design |
| 31 | + |
| 32 | +[design]: #detailed-design |
| 33 | + |
| 34 | +## Broken Packages |
| 35 | + |
| 36 | +Packages that are marked as broken unconditionally platforms should be removed after one full NixOS release cycle. |
| 37 | +If the package had dependencies, those dependencies are also marked as indirectly broken. |
| 38 | +If they are not functional without the broken package, they should be removed as well. |
| 39 | + |
| 40 | +## Unmaintained packages |
| 41 | + |
| 42 | +Packages with an empty maintainer field that does not have packages depending on it, should |
| 43 | +be removed after 2 months. Ideally we have an automation or semi-automation that creates pull requests for that (see future work). |
| 44 | + |
| 45 | +If a NixOS module depends on any of removed package, this module gets removed as well, if it is non-functional without the package. |
| 46 | +In `pkgs/top-level/aliases.nix` we can link to the pull request that removed the package, |
| 47 | +to make it easier for people to recover the nix expression. |
| 48 | + |
| 49 | +In the pull request that removes a package, we also will ping people that have modified/updated the package excluding those that only |
| 50 | +touched the package as part of treewide. |
| 51 | + |
| 52 | +# Examples and Interactions |
| 53 | + |
| 54 | +[examples-and-interactions]: #examples-and-interactions |
| 55 | + |
| 56 | +- |
| 57 | + |
| 58 | +# Drawbacks |
| 59 | + |
| 60 | +[drawbacks]: #drawbacks |
| 61 | + |
| 62 | +Some maintained packages might still have users that won't be able to use the package, |
| 63 | +but the hope is that the removal of unmaintained package will lead to these people |
| 64 | +stepping up as a maintainer. Recovering from the git history should be easy in that case. |
| 65 | + |
| 66 | +# Alternatives |
| 67 | + |
| 68 | +[alternatives]: #alternatives |
| 69 | + |
| 70 | +Keep all packages. |
| 71 | + |
| 72 | +# Prior art |
| 73 | + |
| 74 | +[prior-art]: #prior-art |
| 75 | + |
| 76 | +- Most Linux distributions have rules around removing unmaintained packages i.e. Debian. |
| 77 | +- [Nixpkgs eval time is increasing too fast](https://github.com/NixOS/nixpkgs/issues/320528): |
| 78 | + This issue discusses how we can improve the evaluation time. |
| 79 | + |
| 80 | +# Unresolved questions |
| 81 | + |
| 82 | +[unresolved]: #unresolved-questions |
| 83 | + |
| 84 | +? |
| 85 | + |
| 86 | +# Future work |
| 87 | + |
| 88 | +[future]: #future-work |
| 89 | + |
| 90 | +- Write automation that will open pull request to remove packages. |
| 91 | +- Add deprecation warnings for packages that are about to become removed, so that potential users are notified |
0 commit comments