chiark / gitweb /
[DR] Consistent use of <literal> tag
[developers-reference.git] / pkgs.dbk
index 07b3f85b6d3932a3d02736f7808611417bec4574..03a6919e5bbbe3305c540100a252aec66f86ebb3 100644 (file)
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -1520,12 +1520,13 @@ still be present in the <ulink url="&snap-debian-org;">snapshot archive</ulink>.
 </para>
 <para>
 The version control system used by the previous maintainer might contain useful
-changes, so it might be a good idea to have a look there.  Check if the control
+changes, so it might be a good idea to have a look there.  Check if the <filename>control</filename>
 file of the previous package contained any headers linking to the version
 control system for the package and if it still exists.
 </para>
 <para>
-Package removals from unstable (not testing, stable or oldstable) trigger the
+Package removals from <literal>unstable</literal> (not <literal>testing</literal>,
+<literal>stable</literal> or <literal>oldstable</literal>) trigger the
 closing of all bugs related to the package. You should look through all the
 closed bugs (including archived bugs) and unarchive and reopen any that were
 closed in a version ending in <literal>+rm</literal> and still apply. Any that
@@ -2137,26 +2138,17 @@ It also has the
 benefit of making it visually clear that a package in the archive was not made
 by the official maintainer.
 </para>
-
 <para>
 If you upload a package to testing or stable, you sometimes need to "fork" the
 version number tree. This is the case for security uploads, for example.  For
 this, a version of the form
-<literal>+deb<replaceable>XY</replaceable>u<replaceable>Z</replaceable></literal>
-should be used, where <replaceable>X</replaceable> and
-<replaceable>Y</replaceable> are the major and minor release numbers, and
-<replaceable>Z</replaceable> is a counter starting at <literal>1</literal>.
-When the release number is not yet known (often the case for
-<literal>testing</literal>, at the beginning of release cycles), the lowest
-release number higher than the last stable release number must be used.  For
-example, while Lenny (Debian 5.0) is stable, a security NMU to stable for a
-package at version <literal>1.5-3</literal> would have version
-<literal>1.5-3+deb50u1</literal>, whereas a security NMU to Squeeze would get
-version <literal>1.5-3+deb60u1</literal>. After the release of Squeeze, security
-uploads to the <literal>testing</literal> distribution will be versioned
-<literal>+deb61uZ</literal>, until it is known whether that release will be
-Debian 6.1 or Debian 7.0 (if that becomes the case, uploads will be versioned
-as <literal>+deb70uZ</literal>).
+<literal>+deb<replaceable>X</replaceable>u<replaceable>Y</replaceable></literal>
+should be used, where <replaceable>X</replaceable> is the major release number,
+and <replaceable>Y</replaceable> is a counter starting at <literal>1</literal>.
+For example, while Wheezy (Debian 7.0) is stable, a security NMU to stable for
+a package at version <literal>1.5-3</literal> would have version
+<literal>1.5-3+deb7u1</literal>, whereas a security NMU to Jessie would get
+version <literal>1.5-3+deb8u1</literal>.
 </para>
 </section>