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 <literal>stable</literal> distribution +Special case: uploads to the <literal>stable</literal> and +<literal>oldstable</literal> 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.