Debian Project Leader Andreas Tille has unveiled an initial plan to tackle dormant packages, a growing issue for the venerable Linux distro.

Debian is the second-oldest Linux distro in existence, and serves as the basis for countless others. Debian also boasts one of the largest software repositories, but not all of that software is actively maintained. Unfortunately, as Tille points out in a message to the Debian mailing list, as the repo has grown, the number of poorly maintained or dormant packages has increased.

Debian was founded on the principle that each piece of software should be maintained by someone with expertise in it–typically a single, responsible maintainer. This model formed the historical foundation of Debian’s packaging system and helped establish high standards of quality and accountability. However, as the project has grown and the number of packages has expanded, this model no longer scales well in all areas. Team maintenance has since emerged as a practical complement, allowing multiple contributors to share responsibility and reduce bottlenecks–depending on each team’s internal policy.

While working on the Bug of the Day initiative[d1], I observed a significant number of packages that have not been updated in a long time. In the case of team-maintained packages, addressing this is often straightforward: team uploads can be made, or the team can be asked whether the package should be removed. We’ve also identified many packages that would fit well under the umbrella of active teams, such as language teams like Debian Perl and Debian Python, or blends like Debian Games and Debian Multimedia. Often, no one has taken action–not because of disagreement, but simply due to inattention or a lack of initiative.

In addition, we’ve found several packages that probably should be removed entirely. In those cases, we’ve filed bugs with pre-removal warnings, which can later be escalated to removal requests.

Tille then goes on to outline the provisions that currently exist to address poorly maintained packages, but says they don’t always allow the project to react fast enough, nor are the current tools for identifying such packages robust enough.

Tille then mentions a new process being trialed, as well as his intention of bringing the topic up for discussion at the upcoming DebConf25.

The Package Salvage team is currently trialing a process we’ve provisionally called “Intend to NMU” (ITN). The name is admittedly questionable–some have suggested alternatives like “Intent to Orphan”–and discussion about this is ongoing on debian-devel [d5]. The mechanism is intended for situations where packages appear inactive but aren’t yet formally orphaned, introducing a clear 21-day notice period before NMUs, similar in spirit to the existing ITS process. The discussion has sparked suggestions for expanding NMU rules[d6].

While it is crucial not to undermine the autonomy of maintainers who remain actively involved, we also must not allow a strict interpretation of this autonomy to block needed improvements to obviously neglected packages.

To be clear: I do not propose to change the rights of maintainers who are clearly active and invested in their packages. That model has served us well. However, we must also be honest that, in some cases, maintainers stop contributing–quietly and without transition plans. In those situations, we need more agile and scalable procedures to uphold Debian’s high standards.

To that end, I’ve registered a BoF session for DebConf25 to discuss potential improvements in how we handle dormant packages. These discussions will be prepared during a sprint at DebCamp, where I hope to work with others on concrete ideas.

Tille’s email underscores some of the challenges that face open-source projects and maintainers. It’s not uncommon for developers to bring apps and packages to a distro and maintain them for a while, but then stop due to any number of events or circumstances. When that happens, projects like Debian need a way to identify those packages and respond accordingly.