X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=pkgs.dbk;h=f6206d0a939b8f5d3452d5e82ab1463648e1e2f8;hb=fd33305f4875ecb7266063a04b549aad9532ecce;hp=db52c3d6bb05241f377d4e4e53c8706fcaa02f55;hpb=13699b39a41ac8d65b810df74ff122f2fbf95807;p=developers-reference.git
diff --git a/pkgs.dbk b/pkgs.dbk
index db52c3d..f6206d0 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.
@@ -284,16 +284,25 @@ It is not possible to upload a package into several distributions at the same
time.
-Special case: uploads to the stable distribution
+Special case: uploads to the stable and
+oldstable distributions
Uploading to stable means that the package will transfered
-to the proposed-updates-new-queue for review by the stable
+to the proposed-updates-new queue for review by the stable
release managers, and if approved will be installed in
stable-proposed-updates directory of the Debian archive.
From there, it will be included in stable with the next
point release.
+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 stable. Always
+be verbose and detailed in your changelog entries for uploads to the
+stable distribution.
+
+
Extra care should be taken when uploading to stable.
Basically, a package should only be uploaded to stable if
one of the following happens:
@@ -321,7 +330,10 @@ security problems as well. However, this practice is deprecated, as uploads
used for Debian security advisories are automatically copied to the appropriate
proposed-updates archive when the advisory is released.
See 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 DSA, the stable release
+managers are usually willing to include your fix nonetheless in a regular
+upload to stable.
Changing anything else in the package that isn't important is discouraged,
@@ -338,19 +350,9 @@ rejected. Making changes to dependencies of other packages (by messing with
making those other packages uninstallable, is strongly discouraged.
-The Release Team (which can be reached at
-&email-debian-release;) will regularly evaluate the uploads to
-stable-proposed-updates and decide if your package can be
-included in stable. Please be clear (and verbose, if
-necessary) in your changelog entries for uploads to
-stable, because otherwise the package won't be considered
-for inclusion.
-
-
-It's best practice to speak with the stable release manager
-before uploading to
-stable/stable-proposed-updates, so
-that the uploaded package fits the needs of the next point release.
+Uploads to the oldstable distributions are possible as
+long as it hasn't been archived. The same rules as for stable
+ apply.
@@ -1108,7 +1110,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).
@@ -1222,14 +1224,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
@@ -1249,7 +1273,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
@@ -1264,7 +1293,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;.
@@ -1579,9 +1610,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.
@@ -2190,7 +2221,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.
@@ -2316,7 +2347,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.