Skip to content

Commit 640f7bf

Browse files
committed
[RFC 0180] Remove broken and unmaintained leaf packages
1 parent 62d1245 commit 640f7bf

1 file changed

Lines changed: 90 additions & 0 deletions

File tree

Lines changed: 90 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,90 @@
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 extend
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.
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+
?

0 commit comments

Comments
 (0)