5.1. New packages

If you want to create a new package for the Debian distribution, you should first check the Work-Needing and Prospective Packages (WNPP) list. Checking the WNPP list ensures that no one is already working on packaging that software, and that effort is not duplicated. Read the WNPP web pages for more information.

Assuming no one else is already working on your prospective package, you must then submit a bug report (Bug reporting) against the pseudo-package wnpp describing your plan to create a new package, including, but not limiting yourself to, the description of the package (so that others can review it), the license of the prospective package, and the current URL where it can be downloaded from.

You should set the subject of the bug to ITP:foo--short description, substituting the name of the new package for foo. The severity of the bug report must be set to wishlist. Please send a copy to debian-devel@lists.debian.org by using the X-Debbugs-CC header (don’t use CC:, because that way the message’s subject won’t indicate the bug number). If you are packaging so many new packages (>10) that notifying the mailing list in separate messages is too disruptive, send a summary after filing the bugs to the debian-devel list instead. This will inform the other developers about upcoming packages and will allow a review of your description and package name.

Please include a Closes: #nnnnn entry in the changelog of the new package in order for the bug report to be automatically closed once the new package is installed in the archive (see When bugs are closed by new uploads).

If you think your package needs some explanations for the administrators of the NEW package queue, include them in your changelog, send to ftpmaster@debian.org a reply to the email you receive as a maintainer after your upload, or reply to the rejection email in case you are already re-uploading.

When closing security bugs include CVE numbers as well as the Closes: #nnnnn. This is useful for the security team to track vulnerabilities. If an upload is made to fix the bug before the advisory ID is known, it is encouraged to modify the historical changelog entry with the next upload. Even in this case, please include all available pointers to background information in the original changelog entry.

There are a number of reasons why we ask maintainers to announce their intentions:

• It helps the (potentially new) maintainer to tap into the experience of people on the list, and lets them know if anyone else is working on it already.

• It lets other people thinking about working on the package know that there already is a volunteer, so efforts may be shared.

• It lets the rest of the maintainers know more about the package than the one line description and the usual changelog entry Initial release that gets posted to debian-devel-changes@lists.debian.org.

• It is helpful to the people who live off unstable (and form our first line of testers). We should encourage these people.

• The announcements give maintainers and other interested parties a better feel of what is going on, and what is new, in the project.

Please see https://ftp-master.debian.org/REJECT-FAQ.html for common rejection reasons for a new package.