What Is a Debian NMU and When Is It Allowed?

A Non-Maintainer Upload (NMU) in the Debian operating system is a process that allows a developer other than the designated package maintainer to fix bugs and upload a new version of a package. This article explains the technical definition of an NMU, the strict rules governing when it is permissible, the standard versioning conventions, and the established etiquette required to respect package maintainers while ensuring the health of the Debian archive.

Defining a Non-Maintainer Upload (NMU)

In Debian, every package has one or more designated maintainers listed in its metadata who are primarily responsible for its lifecycle, packaging updates, and bug fixes. An NMU occurs when someone not listed in the Maintainer or Uploaders fields of the debian/control file uploads a modified package to the archive.

NMUs are a vital quality-assurance mechanism. They prevent the Debian archive from stalling when individual maintainers become temporarily unavailable, unresponsive, or overwhelmed, especially leading up to a new distribution release.

When Is an NMU Permissible?

An NMU is not an opportunity to take over a package, overhaul its build system, or make stylistic packaging changes. Debian policy dictates that NMUs are permissible only under specific, justifiable circumstances:

  1. Fixing Release-Critical (RC) Bugs: The most common justification for an NMU is resolving a Release-Critical bug (severity serious, grave, or critical) that prevents a package from being included in the next stable release.
  2. Security Patches: Vulnerabilities tracked by the Debian Security Team that require immediate resolution often warrant an NMU if the primary maintainer cannot act quickly.
  3. Archive-Wide Transitions: NMUs are allowed during broad archive changes, such as library transitions, compiler updates, or architecture-specific fixes, usually coordinated by release teams.
  4. Maintainer Consent or Request: An NMU is entirely permissible if the maintainer explicitly asks for help or acknowledges and approves a contributor's proposed upload.
  5. Maintainer Inactivity: If a maintainer is unresponsive to critical bugs and communication attempts across a significant period, contributors may step in to keep the package functional.

NMUs are generally not permitted for minor bug fixes, cosmetic adjustments, or packaging updates to new upstream versions unless explicit maintainer consent has been granted.

Key NMU Rules and Best Practices

To avoid conflict and maintain software stability, contributors performing an NMU must follow strict procedures outlined in the Debian Developer's Reference:

  • Keep Changes Minimal: The modification must strictly target the bug in question. Intrusive changes, packaging rewrites, or unnecessary dependency updates are prohibited.
  • Communicate via the BTS: Before uploading, the contributor must submit a proposed patch to the relevant bug report in the Debian Bug Tracking System (BTS) and declare their intent to NMU.
  • Use the DELAYED Queue: Unless an upload has maintainer approval or addresses an urgent security issue, it should be uploaded to the DELAYED queue (e.g., DELAYED/2 to DELAYED/10 days). This delay gives the official maintainer a grace period to review the patch, upload their own fix, or cancel the NMU.
  • Document Properly in Changelog: The upload must be clearly identified in debian/changelog by stating * Non-maintainer upload. followed by the rationale and the bugs closed.

Version Numbering Conventions

NMU version numbers are structured specifically so they do not conflict with future maintainer updates:

  • Non-native packages (source code from third party): An extra minor point is appended to the Debian revision. For example, if the current version is 1.4-2, an NMU becomes 1.4-2.1. If an NMU is based on a native source without a previous Debian revision (e.g., 1.4), it becomes 1.4+nmu1.
  • Native packages (Debian-specific software): A suffix is added to the version number, such as 2.0+nmu1.

This numbering ensures the regular maintainer can later upload standard revisions (like 1.4-3) that cleanly supersede the NMU in Debian's package management system.