Translation(s): none

Package Salvaging is the process by which one attempts to save a package that, while not officially orphaned, appear poorly maintained or completely unmaintained. This is a weaker and faster procedure than orphaning a package officially through powers of the MIA team. Salvaging a package is not meant to replace MIA handling, and in contrast to it, it does not comment about the overall activity of a maintainer. Instead, it handles a package maintainership transition for a single package only, leaving any other package or Debian membership or upload rights (when applicable) untouched.

For the description of the package salvaging process, please see the chapter Package Salvaging in the Developer's reference.

Eligibility requirements for a package

How to use the criteria

The following criteria can be used to determine whether a package is eligible for salvaging or not. This conservative criteria represent Debian project consensus and enable especially new maintainers -- if followed -- to assess the eligibility without the need to fear being called a hijacker later. More experienced maintainers are allowed to deviate from them on a case-by-case basis but must be prepared to defend their point of view when challenged. If the maintainer is not sure about their judgement or simply want to be on the safe side, they should follow the criteria as well.

The (conservative) criteria

A package is eligible for salvaging if it is in clear need of some love and care, i.e. there are open bugs, missing upstream releases, or there is work needed from a quality-assurance perspective;
AND there is the need to upload the package to deal with these issues;
AND at least one of these criteria applies:

The Level of activity should be defined "in favour" of the maintainer if in doubt. A maintainer may ask for help or welcome a NMU. This counts as activity with respect to salvage criteria. If a package lacks uploads, there is no visible bug triaging or no answers to bugs at all, and – if applicable – the source package's VCS does not show commits, this is an indication that the package is not well maintained.

Changes to the criteria

Any changes to the criteria set above must be discussed on the Debian-devel mailing list before and the change can only be made if consensus is reached on the change.


Q: Are team-maintained packages also subject to salvaging?
A: Team-maintained packages are not really special in this aspect and the process should be applicable for them too. Like any maintainer and uploader on the package, members of the listed packaging team can also actively veto or allow salvaging (but not against the expressed will of the maintainer).
Q: The salvaging step says that I might be offered co-maintainership instead, but this is not something I want to do. Or the maintainer asks me to be maintainer instead of co-maintainer, but I do not want to do this. Do I have to? Do I really have to join the team or offer the salvager to join the team?
A: Of course you are not obliged to do anything in Debian you do not want to. On the other hand, you cannot salvage a package if the current maintainer/uploaders/team disagrees with the conditions. But please understand that those offers provides beneficial opportunities to all parties, so they should be at least considered. Beside, please be encouraged to discuss that with the maintainers/teams to find mutually agreeable solutions.
Q: The new upstream version is not suitable for Debian! How can I avoid my package being salvaged?
A: Please document this circumstance by filing a bug report to make this visible for potential people that are interested on a updated package version.
Q: I do not have time to fix that bug at the moment, but I will do so before the freeze. How to avoid being salvaged?
A: Explain that in a response to the bug in question. That's activity shown on the package and makes it ineligible for salvaging. (Though it would be great if you could add some background information/explanations as well.)
Q: There are many loopholes in the process, allowing a (malicious) maintainer to game things!
A: The process foundation is on "honest" maintainers not wanting to harm Debian on purpose (for which we'd have other kind of processes).

See also

Page Copyright


GPLv2 or later, at your option


Tobias Frost

see DebianWiki/LicencingTerms for info about wiki content copyright.

  1. A NMU is automatically acknowledged if there is a subsequent upload of the maintainer including the content/fixes of the NMU. (1)

  2. Can also be one bug, constantly modified when new upstream versions became available (2)