Debian Bug Severity Levels Explained

Debian utilizes a structured Bug Tracking System (BTS) to classify software issues according to their impact on system stability, security, and project policy. This article provides a comprehensive overview of the seven distinct severity levels assigned to Debian bug reports, explaining how maintainers prioritize fixes and determine which issues prevent software from entering the Debian stable release.

Release-Critical Severity Levels

Debian designates the top three severity levels as "Release-Critical" (RC). Any package containing an open RC bug is automatically disqualified from migrating into the Debian testing branch and will block the release of a new Debian stable distribution until resolved.

  • Critical: This is the highest severity level. It is reserved for bugs that break unrelated software or the entire system, cause severe data loss, or introduce a major security vulnerability on systems where the package is installed.
  • Grave: A bug marked as grave makes the specific package completely or almost completely unusable. It also applies to issues that cause data loss specifically for the users of that package, or expose a security vulnerability affecting the package itself.
  • Serious: This level applies to severe violations of the Debian Policy Manual. It is also used when, in the opinion of the package maintainer or the Debian Release Team, the bug makes the package totally unfit for release, even if it does not qualify as critical or grave.

Non-Critical Severity Levels

The remaining four severity levels classify everyday defects, minor discrepancies, and proposed enhancements. While they do not inherently block a Debian release, they help users and developers understand the urgency of a problem.

  • Important: This designation is for a bug that has a major negative effect on the usability of a package without rendering it completely unusable for everyone. It typically represents substantial functional failures affecting a common use case.
  • Normal: The default value applied to newly filed bugs. It covers standard defects, unexpected behaviors, and localized errors that do not severely degrade the overall utility of the software.
  • Minor: This category represents non-functional issues that do not affect the usefulness of the package. Common examples include minor typographical errors in documentation, minor user interface quirks, or small cosmetic problems that are typically easy to fix.
  • Wishlist: This level is used for feature requests, architectural improvements, and general enhancement proposals. It is also used for bugs that are deemed too difficult to fix without a complete rewrite or redesign of the underlying software architecture.