</para>
<para>
There are several possible values for this field: <literal>stable</literal>,
-<literal>unstable</literal>, <litersl>testing-proposed-updates</literal> and
+<literal>unstable</literal>, <literal>testing-proposed-updates</literal> and
<literal>experimental</literal>. Normally, packages are uploaded into
<literal>unstable</literal>.
</para>
time.
</para>
<section id="upload-stable">
-<title>Special case: uploads to the <literal>stable</literal> distribution</title>
+<title>Special case: uploads to the <literal>stable</literal> and
+<literal>oldstable</literal> distributions</title>
<para>
Uploading to <literal>stable</literal> means that the package will transfered
-to the <literal>proposed-updates-new</literal>-queue for review by the stable
+to the <literal>proposed-updates-new</literal> queue for review by the stable
release managers, and if approved will be installed in
<filename>stable-proposed-updates</filename> directory of the Debian archive.
From there, it will be included in <literal>stable</literal> with the next
point release.
</para>
<para>
+To ensure that your upload will be accepted, you should discuss the changes
+with the stable release team before you upload. For that, send a mail to
+the &email-debian-release; mailing list, including the patch you want to
+apply to the package version currently in <literal>stable</literal>. Always
+be verbose and detailed in your changelog entries for uploads to the
+<literal>stable</literal> distribution.
+</para>
+<para>
Extra care should be taken when uploading to <literal>stable</literal>.
Basically, a package should only be uploaded to <literal>stable</literal> if
one of the following happens:
used for Debian security advisories are automatically copied to the appropriate
<filename>proposed-updates</filename> archive when the advisory is released.
See <xref linkend="bug-security"/> for detailed information on handling
-security problems.
+security problems. If the security teams deems the problem to be too
+benign to be fixed through a <literal>DSA</literal>, the stable release
+managers are usually willing to include your fix nonetheless in a regular
+upload to <literal>stable</literal>.
</para>
<para>
Changing anything else in the package that isn't important is discouraged,
making those other packages uninstallable, is strongly discouraged.
</para>
<para>
-The Release Team (which can be reached at
-&email-debian-release;) will regularly evaluate the uploads to
-<literal>stable-proposed-updates</literal> and decide if your package can be
-included in <literal>stable</literal>. Please be clear (and verbose, if
-necessary) in your changelog entries for uploads to
-<literal>stable</literal>, because otherwise the package won't be considered
-for inclusion.
-</para>
-<para>
-It's best practice to speak with the stable release manager
-<emphasis>before</emphasis> uploading to
-<literal>stable</literal>/<literal>stable-proposed-updates</literal>, so
-that the uploaded package fits the needs of the next point release.
+Uploads to the <literal>oldstable</literal> distributions are possible as
+long as it hasn't been archived. The same rules as for <literal>stable
+</literal> apply.
</para>
</section>
Unless the upstream source has been uploaded to <literal>security.debian.org
</literal> before (by a previous security update), build the upload with full
upstream source (<literal>dpkg-buildpackage -sa</literal>). If there has been
-a previous upload to </literal>security.debian.org</literal> with the same
+a previous upload to <literal>security.debian.org</literal> with the same
upstream version, you may upload without upstream source (<literal>
dpkg-buildpackage -sd</literal>).
</para>
If for some reason you want to completely remove a package (say, if it is an
old compatibility library which is no longer required), you need to file a bug
against <literal>ftp.debian.org</literal> asking that the package be removed;
-as all bugs, this bug should normally have normal severity. Make sure you
-indicate which distribution the package should be removed from. Normally, you
-can only have packages removed from <literal>unstable</literal> and
-<literal>experimental</literal>. Packages are not removed from
+as all bugs, this bug should normally have normal severity.
+The bug title should be in the form <literal>RM: <replaceable>package
+</replaceable> <replaceable>[architecture list]</replaceable> --
+<replaceable>reason</replaceable></literal>, where <replaceable>package</replaceable>
+is the package to be removed and <replaceable>reason</replaceable> is a
+short summary of the reason for the removal request.
+<replaceable>[architecture list]</replaceable> is optional and only needed
+if the removal request only applies to some architectures, not all. Note
+that the <command>reportbug</command> will create a title conforming
+to these rules when you use it to report a bug against the <literal>
+ftp.debian.org</literal> pseudo-package.
+</para>
+
+<para>
+If you want to remove a package you maintain, you should note this in
+the bug title by prepending <literal>ROM</literal> (Request Of Maintainer).
+There are several other standard acronyms used in the reasoning for a package
+removal, see <ulink url="http://&ftp-master-host;/removals.html"></ulink>
+for a complete list. That page also provides a convenient overview of
+pending removal requests.
+</para>
+
+<para>
+Note that removals can only be done for the <literal>unstable
+</literal>, <literal>experimental</literal> and <literal>stable
+</literal> distribution. Packages are not removed from
<literal>testing</literal> directly. Rather, they will be removed
automatically after the package has been removed from
-<literal>unstable</literal> and no package in <literal>testing</literal>
-depends on it.
+<literal>unstable</literal> and no package in <literal>testing
+</literal> depends on it.
</para>
<para>
There is one exception when an explicit removal request is not necessary: If a
<para>
Usually you only ask for the removal of a package maintained by yourself. If
you want to remove another package, you have to get the approval of its
-maintainer.
+maintainer. Should the package be orphaned and thus have no maintainer,
+you should first discuss the removal request on &email-debian-qa;. If
+there is a consensus that the package should be removed, you should
+reassign and retitle the <literal>O:</literal> bug filed against the
+<literal>wnpp</literal> package instead of filing a new bug as
+removal request.
</para>
<para>
Further information relating to these and other package removal related topics
showpkg <replaceable>package</replaceable></literal>, the program will show
details for <replaceable>package</replaceable>, including reverse depends.
Other useful programs include <literal>apt-cache rdepends</literal>,
-<command>apt-rdepends</command> and <command>grep-dctrl</command>. Removal of
+<command>apt-rdepends</command>, <command>build-rdeps</command> (in the
+<systemitem role="package">devscripts</systemitem> package) and
+<command>grep-dctrl</command>. Removal of
orphaned packages is discussed on &email-debian-qa;.
</para>
<para>
<para>
The ``magic'' for a recompilation-only NMU is triggered by using a suffix
appended to the package version number, following the form <literal>
-b<replaceable>number<replaceable>.
+b<replaceable>number</replaceable></literal>.
For instance, if the latest version you are recompiling against was version
-<literal>2.9-3<literal>, your binary-only NMU should carry a version of
+<literal>2.9-3</literal>, your binary-only NMU should carry a version of
<literal>2.9-3+b1</literal>. If the latest version was <literal>3.4+b1
</literal> (i.e, a native package with a previous recompilation NMU), your
binary-only NMU should have a version number of <literal>3.4+b2</literal>.
They must be in sync on all architectures and mustn't have dependencies that
make them uninstallable; they also have to have generally no known
release-critical bugs at the time they're installed into <literal>testing
-<literal>. This way, <literal>testing</literal> should always be close to
+</literal>. This way, <literal>testing</literal> should always be close to
being a release candidate. Please see below for details.
</para>
</section>
</informaltable>
<para>
The package is out of date on alpha in <literal>unstable</literal>, and will
-not go to <literal>testing. Removing the package would not help at all, the
+not go to <literal>testing</literal>. Removing the package would not help at all, the
package is still out of date on <literal>alpha</literal>, and will not
propagate to testing.
</para>
~ianmdlvl / developers-reference.git / blobdiff