X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=developers-reference.git;a=blobdiff_plain;f=pkgs.dbk;h=d96c0ae8ac6c88d7ee3e124928c656ff5b4cc72a;hp=3a2813b1ac580331444101bed94de0d7a0afb2d3;hb=4b575d5020486873569980c2e7d673fa3a60fcbc;hpb=0adcfcc1b39c4d51e7131f1157a3919ab367565b
diff --git a/pkgs.dbk b/pkgs.dbk
index 3a2813b..d96c0ae 100644
--- a/pkgs.dbk
+++ b/pkgs.dbk
@@ -270,7 +270,7 @@ The package build process extracts this information from the first line of the
There are several possible values for this field: stable,
-unstable, testing-proposed-updates and
+unstable, testing-proposed-updates and
experimental. Normally, packages are uploaded into
unstable.
@@ -662,11 +662,25 @@ procedure.
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 IRC 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 packagename@packages.debian.org and explaining
+your reasons in that mail. Please note that a simple reassignment is
+not 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.
+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.
+
+
+
+
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
@@ -721,9 +735,9 @@ several developers working on the same package.
-Once a corrected package is available in the unstable
-distribution, you can close the bug. This can be done automatically, read
- .
+Once a corrected package is available in the archive, the bug should be
+closed indicating the version in which it was fixed. This can be done
+automatically, read .
@@ -1110,7 +1124,7 @@ uploads as well.
Unless the upstream source has been uploaded to security.debian.org
before (by a previous security update), build the upload with full
upstream source (dpkg-buildpackage -sa). If there has been
-a previous upload to security.debian.org with the same
+a previous upload to security.debian.org with the same
upstream version, you may upload without upstream source (
dpkg-buildpackage -sd).
@@ -1224,14 +1238,36 @@ described in .
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 ftp.debian.org 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 unstable and
-experimental. Packages are not removed from
+as all bugs, this bug should normally have normal severity.
+The bug title should be in the form RM: package
+[architecture list] --
+reason, where package
+is the package to be removed and reason is a
+short summary of the reason for the removal request.
+[architecture list] is optional and only needed
+if the removal request only applies to some architectures, not all. Note
+that the reportbug will create a title conforming
+to these rules when you use it to report a bug against the
+ftp.debian.org pseudo-package.
+
+
+
+If you want to remove a package you maintain, you should note this in
+the bug title by prepending ROM (Request Of Maintainer).
+There are several other standard acronyms used in the reasoning for a package
+removal, see
+for a complete list. That page also provides a convenient overview of
+pending removal requests.
+
+
+
+Note that removals can only be done for the unstable
+, experimental and stable
+ distribution. Packages are not removed from
testing directly. Rather, they will be removed
automatically after the package has been removed from
-unstable and no package in testing
-depends on it.
+unstable and no package in testing
+ depends on it.
There is one exception when an explicit removal request is not necessary: If a
@@ -1251,7 +1287,12 @@ supersedes the one to be removed.
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 O: bug filed against the
+wnpp package instead of filing a new bug as
+removal request.
Further information relating to these and other package removal related topics
@@ -1266,7 +1307,9 @@ role="package">apt package. When invoked as apt-cache
showpkg package, the program will show
details for package, including reverse depends.
Other useful programs include apt-cache rdepends,
-apt-rdepends and grep-dctrl. Removal of
+apt-rdepends, build-rdeps (in the
+devscripts package) and
+grep-dctrl. Removal of
orphaned packages is discussed on &email-debian-qa;.
@@ -1296,14 +1339,20 @@ occur too often anyway.
Replacing or renaming packages
-When you make a mistake naming your package, you should follow a two-step
-process to rename it. First, set your debian/control file
-to replace and conflict with the obsolete name of the package (see the Debian Policy Manual for
-details). Once you've uploaded the package and the package has moved into the
-archive, file a bug against ftp.debian.org 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 debian/control file to
+reflect the new name and to replace, provide and conflict with the
+obsolete package name (see the
+Debian Policy Manual for details). Please note that you
+should only add a Provides 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
+ftp.debian.org asking to remove the package with the
+obsolete name (see ). Do not forget
+to properly reassign the package's bugs at the same time.
At other times, you may make a mistake in constructing your package and wish to
@@ -1581,9 +1630,9 @@ source code).
The ``magic'' for a recompilation-only NMU is triggered by using a suffix
appended to the package version number, following the form
-bnumber.
+bnumber.
For instance, if the latest version you are recompiling against was version
-2.9-3, your binary-only NMU should carry a version of
+2.9-3, your binary-only NMU should carry a version of
2.9-3+b1. If the latest version was 3.4+b1
(i.e, a native package with a previous recompilation NMU), your
binary-only NMU should have a version number of 3.4+b2.
@@ -2192,7 +2241,7 @@ after they have undergone some degree of testing in
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 testing
-. This way, testing should always be close to
+. This way, testing should always be close to
being a release candidate. Please see below for details.
@@ -2232,7 +2281,7 @@ available in unstable, but not affecting the version in
It must be available on all architectures on which it has previously been built
-in unstable. may be of interest
+in unstable. may be of interest
to check that information;
@@ -2318,7 +2367,7 @@ Consider this example:
The package is out of date on alpha in unstable, and will
-not go to testing. Removing the package would not help at all, the
+not go to testing. Removing the package would not help at all, the
package is still out of date on alpha, and will not
propagate to testing.