Debian RFP Bugs: Tracking Community Demand

A Request for Package (RFP) bug in the Debian operating system is a formal submission filed in the Debian Bug Tracking System that asks volunteer maintainers to package and include new software in the official distribution. This article explains the technical purpose of an RFP bug, how it operates within Debian's Work-Needing and Prospective Packages (WNPP) infrastructure, and the specific mechanisms by which it aggregates, tracks, and signals community demand for new tools.

What Is a Request for Package (RFP) Bug?

In the Debian ecosystem, the Bug Tracking System (BTS) does not exclusively handle software defects; it also tracks development workflows and prospective software. An RFP is a specific type of bug report submitted against the wnpp (Work-Needing and Prospective Packages) pseudo-package.

When a user identifies an open-source tool that would benefit the Debian ecosystem but lacks the time, permissions, or packaging knowledge to maintain it themselves, they submit an RFP. The bug report serves as a formal public proposal for another Debian developer or maintainer to adopt the upstream software and create the corresponding .deb package.

To create an RFP, users typically use Debian’s command-line tool reportbug, which guides them through providing essential metadata:

  • Package name: The upstream name of the software.
  • URL: The upstream repository or website.
  • License: Verification that the software complies with the Debian Free Software Guidelines (DFSG).
  • Description: An explanation of what the tool does and why it is useful.

How RFP Bugs Track Community Demand

Debian relies almost entirely on volunteer maintainers who select software to package based on interest, utility, and broader community need. RFP bugs serve as the primary mechanism for measuring this demand in several ways:

  1. Centralized Discovery and Aggregation
    All RFP submissions are cataloged in Debian's WNPP database and mirrored across dedicated mailing lists and web portals. Maintainers seeking new projects browse these listings to identify which tools are missing from the archive.

  2. User Interaction and BTS Feedback
    Users interested in a requested tool can subscribe to the RFP bug report via Debian’s Bug Tracking System. By adding context, technical use cases, or dependency requirements to the bug log, users generate discussion that signals high utility. A bug thread with extensive engagement and multiple confirmations of interest highlights that packaging the software will benefit a wide audience rather than a single niche use case.

  3. Duplication Metrics
    When multiple users request the same tool independently, the BTS allows maintainers to merge duplicate reports. An RFP bug that has multiple merged reports or explicit links to other packaging requests across Debian derivatives (such as Ubuntu) acts as an empirical indicator of rising popularity.

  4. Integration with the Packaging Lifecycle
    When a maintainer decides that an RFP shows sufficient community value and aligns with their packaging workload, they retitle the bug from RFP to ITP (Intent to Package). This transition communicates to the entire community that packaging is actively underway, preventing duplicated effort and closing the loop on the original community request once the software enters Debian's unstable archive.