</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>
If the bug is real but it's caused by another package, just reassign the bug to
the right package. If you don't know which package it should be reassigned to,
you should ask for help on <link linkend="irc-channels">IRC</link> or
-on &email-debian-devel;. Please make sure that the
-maintainer(s) of the package the bug is reassigned to know why you reassigned
-it.
+on &email-debian-devel;. Please inform the maintainer(s) of the package
+you reassign the bug to, for example by Cc:ing the message that does the
+reassign to <email>packagename@packages.debian.org</email> and explaining
+your reasons in that mail. Please note that a simple reassignment is
+<emphasis>not</emphasis> e-mailed to the maintainers of the package
+being reassigned to, so they won't know about it until they look at
+a bug overview for their packages.
</para>
<para>
+If the bug affects the operation of your package, please consider
+cloning the bug and reassigning the clone to the package that really
+causes the behavior. Otherwise, the bug will not be shown in your
+package's bug list, possibly causing users to report the same bug over
+and over again. You should block "your" bug with the reassigned, cloned
+bug to document the relationship.
+</para>
+</listitem>
+<listitem>
+<para>
Sometimes you also have to adjust the severity of the bug so that it matches
our definition of the severity. That's because people tend to inflate the
severity of bugs to make sure their bugs are fixed quickly. Some bugs may even
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>
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>, where <replaceable>package</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
<section id="s5.9.3">
<title>Replacing or renaming packages</title>
<para>
-When you make a mistake naming your package, you should follow a two-step
-process to rename it. First, set your <filename>debian/control</filename> file
-to replace and conflict with the obsolete name of the package (see the <ulink
-url="&url-debian-policy;">Debian Policy Manual</ulink> for
-details). Once you've uploaded the package and the package has moved into the
-archive, file a bug against <literal>ftp.debian.org</literal> asking to remove
-the package with the obsolete name. Do not forget to properly reassign the
-package's bugs at the same time.
+When the upstream maintainers for one of your packages chose to
+rename their software (or you made a mistake naming your package),
+you should follow a two-step process to rename it. In the first
+step, change the <filename>debian/control</filename> file to
+reflect the new name and to replace, provide and conflict with the
+obsolete package name (see the <ulink url="&url-debian-policy;">
+Debian Policy Manual</ulink> for details). Please note that you
+should only add a <literal>Provides</literal> relation if all
+packages depending on the obsolete package name continue to work
+after the renaming. Once you've uploaded the package and the package
+has moved into the archive, file a bug against <literal>
+ftp.debian.org</literal> asking to remove the package with the
+obsolete name (see <xref linkend="removing-pkgs"/>). Do not forget
+to properly reassign the package's bugs at the same time.
</para>
<para>
At other times, you may make a mistake in constructing your package and wish to
<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