X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.sgml;h=a21ed3bb1776bb563e2558bd920bf4e57887bc54;hb=42c4cf7191cff507d20c27cd5e480e3b934b36f2;hp=f64955c1f615143efec57b1d292507eec09b0037;hpb=4d3846471cf785e8bc5623e71adcb46bba604efe;p=developers-reference.git diff --git a/developers-reference.sgml b/developers-reference.sgml index f64955c..a21ed3b 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -5,7 +5,7 @@ %commondata; - + @@ -915,11 +915,38 @@ better feel of what is going on, and what is new, in the project. + Checking the package prior to upload +

+Before you upload your package, you should do basic testing on it. At +a minimum, you should try the following activities (you'll need to +have an older version of the same Debian package around): + + +Install the package and make sure the software works, or upgrade the +package from an older version to your new version if a Debian package +for it already exists. + +Run lintian over the package. You can run +lintian as follows: lintian -v +package-version.changes. This will check the source +package as well as the binary package. If you don't understand the +output that lintian generates, try adding the -i +switch, which will cause lintian to output a very verbose +description of the problem. +

+Normally, a package should not be uploaded if it causes lintian +to emit errors (they will start with E). +

+For more information on lintian, see . + +Downgrade the package to the previous version (if one exists) — this +tests the postrm and prerm scripts. + +Remove the package, then reinstall it. + - Uploading a package - - Generating the changes file + Generating the changes file

When a package is uploaded to the Debian FTP archive, it must be accompanied by a .changes file, which gives directions to the @@ -934,29 +961,10 @@ All of these fields are mandatory for a Debian upload. See the list of control fields in the for the contents of these fields. You can close bugs automatically using the Description field, see . Only the Distribution field is -discussed in this section, since it relates to the archive maintenance -policies. +id="upload-bugfix">. - Picking a distribution -

-Notably, the Distribution field, which originates from the -debian/changelog file, indicates which distribution the -package is intended for. There are four possible values for this -field: `stable', `unstable', `frozen', or `experimental'; these values -can also be combined. Or, if Debian has been frozen, and you -want to get a bug-fix release into frozen, you would set the -distribution to `frozen unstable'. (See for -more information on when to upload to frozen.) Note that it -never makes sense to combine the experimental distribution with -anything else. -

-You should avoid combining `stable' with others because of potential -problems with library dependencies (for your package and for the package -built by the build daemons for other architecture). -See for more information on when and how to -upload to stable. + The original source tarball

The first time a version is uploaded which corresponds to a particular upstream version, the original source tar file should be uploaded and @@ -979,6 +987,32 @@ is some reason why this is not the case, the new version of the original source should be uploaded, possibly by using the -sa flag. + + Picking a distribution +

+The Distribution field, which originates from the first line of +the debian/changelog file, indicates which distribution the +package is intended for. +

+There are four possible values for this field: `stable', `unstable', +`frozen', and `experimental'. Normally, packages are uploaded into +unstable. +

+These values can be combined, but only a few combinations make sense. +If Debian has been frozen, and you want to get a bug-fix release into +frozen, you would set the distribution to `frozen unstable'. +See for more information on uploading to +frozen. +

+You should avoid combining `stable' with others because of potential +problems with library dependencies (for your package and for the package +built by the build daemons for other architecture). +See for more information on when and how to +upload to stable. +

+It never makes sense to combine the experimental distribution +with anything else. + Uploading to frozen

The Debian freeze is a crucial time for Debian. It is our chance to @@ -1058,36 +1092,7 @@ inclusion. - Checking the package prior to upload -

-Before you upload your package, you should do basic testing on it. At -a minimum, you should try the following activities (you'll need to -have an older version of the same Debian package around): - - -Install the package and make sure the software works, or upgrade the -package from an older version to your new version if a Debian package -for it already exists. - -Run lintian over the package. You can run -lintian as follows: lintian -v -package-version.changes. This will check the source -package as well as the binary package. If you don't understand the -output that lintian generates, try adding the -i -switch, which will cause lintian to output a very verbose -description of the problem. -

-Normally, a package should not be uploaded if it causes lintian -to emit errors (they will start with E). -

-For more information on lintian, see . - -Downgrade the package to the previous version (if one exists) — this -tests the postrm and prerm scripts. - -Remove the package, then reinstall it. - - + Uploading a package Uploading to ftp-master