</para>
<para>
The <link linkend="testing">testing</link> distribution is generated
-automatically by taking packages from unstable if they satisfy certain
-criteria. Those criteria should ensure a good quality for packages within
-testing. The update to testing is launched each day after the new packages
+automatically by taking packages from <literal>unstable</literal> if they
+satisfy certain criteria. Those criteria should ensure a good quality for
+packages within <literal>testing</literal>. The update to <literal>testing
+</literal> is launched twice each day, right after the new packages
have been installed. See <xref linkend="testing"/> .
</para>
<para>
<section id="s4.6.4.2">
<title>More information about the testing distribution</title>
<para>
-Packages are usually installed into the `testing' distribution after they have
-undergone some degree of testing in unstable.
+Packages are usually installed into the <literal>testing</literal> distribution
+after they have undergone some degree of testing in <literal>unstable</literal>.
</para>
<para>
For more details, please see the <link linkend="testing">information about
<title>Experimental</title>
<para>
The <literal>experimental</literal> distribution is a special distribution.
-It is not a full distribution in the same sense as `stable' and `unstable' are.
+It is not a full distribution in the same sense as <literal>stable</literal>,
+<literal>testing</literal> and <literal>unstable</literal> are.
Instead, it is meant to be a temporary staging area for highly experimental
software where there's a good chance that the software could break your system,
or software that's just too unstable even for the <literal>unstable</literal>
space on <literal>people.debian.org</literal>.
</para>
<para>
-When uploading to unstable a package which had bugs fixed in experimental,
-please consider using the option <literal>-v</literal> to
-<command>dpkg-buildpackage</command> to finally get them closed.
+When uploading to <literal>unstable</literal> a package which had bugs fixed
+in <literal>experimental</literal>, please consider using the option
+<literal>-v</literal> to <command>dpkg-buildpackage</command> to finally get
+them closed.
</para>
</section>
<title>Release code names</title>
<para>
Every released Debian distribution has a <literal>code name</literal>: Debian
-1.1 is called `buzz'; Debian 1.2, `rex'; Debian 1.3, `bo'; Debian 2.0, `hamm';
-Debian 2.1, `slink'; Debian 2.2, `potato'; Debian 3.0, `woody'; Debian 3.1,
-sarge; Debian 4.0, etch. There is also a ``pseudo-distribution'', called
-`sid', which is the current `unstable' distribution; since packages are moved
-from `unstable' to `testing' as they approach stability, `sid' itself is never
-released. As well as the usual contents of a Debian distribution, `sid'
-contains packages for architectures which are not yet officially supported or
-released by Debian. These architectures are planned to be integrated into the
-mainstream distribution at some future date.
+1.1 is called <literal>buzz</literal>; Debian 1.2, <literal>rex</literal>;
+Debian 1.3, <literal>bo</literal>; Debian 2.0, <literal>hamm</literal>;
+Debian 2.1, <literal>slink</literal>; Debian 2.2, <literal>potato</literal>;
+Debian 3.0, <literal>woody</literal>; Debian 3.1, <literal>sarge</literal>;
+Debian 4.0, <literal>etch</literal>; Debian 5.0, <literal>lenny</literal>
+and the next release will be called <literal>squeeze</literal>.
+There is also a ``pseudo-distribution'', called
+<literal>sid</literal>, which is the current <literal>unstable</literal>
+distribution; since packages are moved from <literal>unstable</literal> to
+<literal>testing</literal> as they approach stability, <literal>sid</literal>
+itself is never released. As well as the usual contents of a Debian
+distribution, <literal>sid</literal> contains packages for architectures which
+are not yet officially supported or released by Debian. These architectures
+are planned to be integrated into the mainstream distribution at some future
+date.
</para>
<para>
Since Debian has an open development model (i.e., everyone can participate and
-follow the development) even the `unstable' and `testing' distributions are
-distributed to the Internet through the Debian FTP and HTTP server network.
-Thus, if we had called the directory which contains the release candidate
-version `testing', then we would have to rename it to `stable' when the version
+follow the development) even the <literal>unstable</literal> and <literal>
+testing</literal> distributions are distributed to the Internet through the
+Debian FTP and HTTP server network. Thus, if we had called the directory which
+contains the release candidate version <literal>testing</literal>, then we
+would have to rename it to <literal>stable</literal> when the version
is released, which would cause all FTP mirrors to re-retrieve the whole
distribution (which is quite large).
</para>
The archive maintenance software will also send the OpenPGP/GnuPG signed
<filename>.changes</filename> file that you uploaded to the appropriate mailing
lists. If a package is released with the <literal>Distribution:</literal> set
-to `stable', the announcement is sent to
+to <literal>stable</literal>, the announcement is sent to
&email-debian-changes;. If a package is released with
-<literal>Distribution:</literal> set to `unstable' or `experimental', the
-announcement will be posted to &email-debian-devel-changes;
-instead.
+<literal>Distribution:</literal> set to <literal>unstable</literal> or
+<literal>experimental</literal>, the announcement will be posted to
+&email-debian-devel-changes; instead.
</para>
<para>
Though ftp-master is restricted, a copy of the installation is available to all
</para>
</section>
-<section id="madison">
-<title>The <command>madison</command> utility</title>
+<section id="dak-ls">
+<title>The <command>dak ls</command> utility</title>
<para>
-<command>madison</command> is a command-line utility that is available on
-<literal>&ftp-master-host;</literal>, and on the mirror on
-<literal>&ftp-master-mirror;</literal>. It uses a single argument corresponding
-to a package name. In result it displays which version of the package is
-available for each architecture and distribution combination. An example will
-explain it better.
+<command>dak ls</command> is part of the dak suite of tools, listing
+available package versions for all known distributions and architectures.
+The <command>dak</command> tool is available on <literal>&ftp-master-host;
+</literal>, and on the mirror on <literal>&ftp-master-mirror;</literal>.
+It uses a single argument corresponding to a package name. An example will
+explain it better:
</para>
<screen>
-$ madison libdbd-mysql-perl
-libdbd-mysql-perl | 1.2202-4 | stable | source, alpha, arm, i386, m68k, powerpc, sparc
-libdbd-mysql-perl | 1.2216-2 | testing | source, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
-libdbd-mysql-perl | 1.2216-2.0.1 | testing | alpha
-libdbd-mysql-perl | 1.2219-1 | unstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
+$ dak ls evince
+evince | 0.1.5-2sarge1 | oldstable | source, alpha, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
+evince | 0.4.0-5 | etch-m68k | source, m68k
+evince | 0.4.0-5 | stable | source, alpha, amd64, arm, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc
+evince | 2.20.2-1 | testing | source
+evince | 2.20.2-1+b1 | testing | alpha, amd64, arm, armel, hppa, i386, ia64, mips, mipsel, powerpc, s390, sparc
+evince | 2.22.2-1 | unstable | source, alpha, amd64, arm, armel, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
</screen>
<para>
In this example, you can see that the version in <literal>unstable</literal>
differs from the version in <literal>testing</literal> and that there has
-been a binary-only NMU of the package for the alpha architecture. Each version
-of the package has been recompiled on most of the architectures.
+been a binary-only NMU of the package for all architectures. Each version
+of the package has been recompiled on all architectures.
</para>
</section>
~ianmdlvl / developers-reference.git / blobdiff