X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=pkgs.dbk;h=8f1f36b9cd1928e497af1ffbc5e1afcd372d2d29;hb=e81cdebedab690ef881d87af6f533e51c026565c;hp=628300063d01d4168c36e58c160079f637ab7a70;hpb=edd829c897de8228d29eb2b84340babd87f2142d;p=developers-reference.git diff --git a/pkgs.dbk b/pkgs.dbk index 6283000..8f1f36b 100644 --- a/pkgs.dbk +++ b/pkgs.dbk @@ -28,14 +28,18 @@ description of the package, the license of the prospective package, and the current URL where it can be downloaded from. -You should set the subject of the bug to ``ITP: foo --- short description'', substituting the name of the -new package for foo. The severity of the bug report -must be set to wishlist. If you feel it's necessary, send -a copy to &email-debian-devel; by putting the address in the -X-Debbugs-CC: header of the message (no, don't use -CC:, because that way the message's subject won't indicate -the bug number). +You should set the subject of the bug to ITP: +foo -- short +description, substituting the name of the new +package for foo. +The severity of the bug report must be set to wishlist. +Please send a copy to &email-debian-devel; by using the X-Debbugs-CC +header (don't use CC:, because that way the message's subject won't +indicate the bug number). If you are packaging so many new packages (>10) +that notifying the mailing list in seperate messages is too disruptive, +do send a summary after filing the bugs to the debian-devel list instead. +This will inform the other developers about upcoming packages and will +allow a review of your description and package name. Please include a Closes: @@ -270,7 +274,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 +666,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 +739,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 +1128,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). @@ -1227,7 +1245,7 @@ against ftp.debian.org asking that the package be removed; 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 +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 @@ -1293,7 +1311,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;. @@ -1323,14 +1343,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 @@ -1608,9 +1634,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. @@ -2219,7 +2245,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.
@@ -2259,7 +2285,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; @@ -2345,7 +2371,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.