<!entity % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!entity cvs-rev "$Revision: 1.202 $">
+ <!entity cvs-rev "$Revision: 1.205 $">
<!-- if you are translating this document, please notate the CVS
revision of the developers reference here -->
<!--
the package (maintainer, version, etc.).
- <sect1>Distribution directories
+ <sect1>Distributions
<p>
The directory system described in the previous chapter is itself
contained within <em>distribution directories</em>. Each
freeze period, since the <em>unstable</em> distribution remains in
place in parallel with <em>testing</em>.
+ <sect2 id="testing">
+ <heading>More information about the testing distribution</heading>
+ <p>
+The scripts that update the <em>testing</em> distribution are run each
+day after the installation of the updated packages. They generate the
+<file>Packages</file> files for the <em>testing</em> distribution, but
+they do so in an intelligent manner trying to avoid any inconsistency
+and trying to use only non-buggy packages.
+ <p>
+The inclusion of a package from <em>unstable</em> is conditional on
+the following:
+<list>
+ <item>
+The package must have been available in <em>unstable</em> for several days;
+the precise number depends on the upload's urgency field. It
+is 10 days for low urgency, 5 days for medium urgency and 2 days for high
+urgency. Those delays may be doubled during a freeze;
+ <item>
+It must have less release-critical bugs than the version available
+in <em>testing</em>;
+ <item>
+It must be available on all architectures on which it has been
+previously built. <ref id="madison"> may be of interest to
+check that information;
+ <item>
+It must not break any dependency of a package that is already available
+in <em>testing</em>;
+ <item>
+The packages on which it depends must either be available in <em>testing</em>
+or they must be accepted into <em>testing</em> at the same time (and they will
+if they respect themselves all the criteria);
+</list>
+ <p>
+To find out whether a package is progressing into testing or not, see the
+testing script output on the <url name="web page of the testing distribution"
+id="&url-testing-maint;">, or use the program <prgn>grep-excuses</prgn>
+which is in the <package>devscripts</package> package. This utility can
+easily be used in a <manref name="crontab" section="5"> to keep one
+informed of the progression of their packages into <em>testing</em>.
+ <p>
+The <file>update_excuses</file> file does not always give the precise reason
+why the package is refused, one may have to find it on their own by looking
+what would break with the inclusion of the package. The <url
+id="&url-testing-maint;" name="testing web page"> gives some more information
+about the usual problems which may be causing such troubles.
+ <p>
+Sometimes, some packages never enter <em>testing</em> because the set of
+inter-relationship is too complicated and can not be sorted out
+by the scripts. In that case, the release manager must be
+contacted, and he will force the inclusion of the packages.
+ <p>
+In general, please refer to the <url name="testing web page"
+id="&url-testing-maint;"> for more information. It also includes
+answers to some of the frequently asked questions.
+
+
<sect2 id="experimental">Experimental
<p>
The <em>experimental</em> distribution is a special distribution.
<example>DELAY=5 dupload --to delayed <changes-file></example>
- <sect id="testing">
- <heading>The "testing" distribution</heading>
- <p>
-The scripts that update the <em>testing</em> distribution are run each day
-after the installation of the
-updated packages. They generate the <file>Packages</file> files for
-the <em>testing</em> distribution, but they do so in an intelligent manner
-trying to avoid any inconsistency and trying to use only
-non-buggy packages.
- <p>The inclusion of a package from <em>unstable</em> is conditional on the following:
-<list>
- <item>
-The package must have been available in <em>unstable</em> for several days;
-the precise number depends on the upload's urgency field. It
-is 10 days for low urgency, 5 days for medium urgency and 2 days for high
-urgency. Those delays may be doubled during a freeze;
- <item>
-It must have less release-critical bugs than the version available
-in <em>testing</em>;
- <item>
-It must be available on all architectures on which it has been
-previously built. <ref id="madison"> may be of interest to
-check that information;
- <item>
-It must not break any dependency of a package that is already available
-in <em>testing</em>;
- <item>
-The packages on which it depends must either be available in <em>testing</em>
-or they must be accepted into <em>testing</em> at the same time (and they will
-if they respect themselves all the criteria);
-</list>
- <p>
-To find out whether a package is progressing into testing or not, see the
-testing script output on the <url name="web page of the testing distribution"
-id="&url-testing-maint;">, or use the program <prgn>grep-excuses</prgn>
-which is in the <package>devscripts</package> package. This utility can
-easily be used in a <manref name="crontab" section="5"> to keep one
-informed of the progression of their packages into <em>testing</em>.
- <p>
-The <file>update_excuses</file> file does not always give the precise reason
-why the package is refused, one may have to find it on their own by looking
-what would break with the inclusion of the package. The <url
-id="&url-testing-maint;" name="testing web page"> gives some more information
-about the usual problems which may be causing such troubles.
- <p>
-Sometimes, some packages never enter <em>testing</em> because the set of
-inter-relationship is too complicated and can not be sorted out
-by the scripts. In that case, the release manager must be
-contacted, and he will force the inclusion of the packages.
- <p>
-In general, please refer to the <url name="testing web page"
-id="&url-testing-maint;"> for more information. It also includes
-answers to some of the frequently asked questions.
-
<sect id="pkg-info">Package information
<p>
In particular, it never makes sense to combine the <em>experimental</em>
distribution with anything else (see <ref id="experimental">).
- <sect1 id="upload-stable">Uploads to <em>stable</em>
+ <sect1 id="upload-stable">
+ <heading>Special case: uploads to the <em>stable</em> distribution</heading>
<p>
Uploading to <em>stable</em> means that the package will be placed into the
<file>stable-proposed-updates</file> directory of the Debian archive for further
<em>stable</em>, because otherwise the package won't be considered for
inclusion.
- <sect1 id="upload-t-p-u">Uploads to <em>testing-proposed-updates</em>
+ <sect1 id="upload-t-p-u">
+ <heading>Special case: uploads to <em>testing-proposed-updates</em></heading>
<p>
The testing distribution is fed with packages from unstable according to the rules
explained in <ref id="testing">. However, the release manager may stop the testing
future.
<p>
Debconf is a great tool but it is often poorly used. Many common mistakes
-are listed in the <manref name="debconf-devel" section="8"> man page.
+are listed in the <manref name="debconf-devel" section="7"> man page.
It is something that you must read if you decide to use debconf.
</sect>
~ianmdlvl / developers-reference.git / blobdiff