+The Deverlopers Database, at <url id="&url-debian-db;">, is an LDAP
+directory for managing Debian developer attributes. You can use this
+resource to search the list of Debian developers. For information on
+keeping your entry the developer database up-to-date, see <ref
+id="user-maint">.
+
+
+ <sect id="servers-mirrors">Mirrors of Debian servers
+ <p>
+The web and FTP servers have several mirrors available. Please do not
+put heavy load on the canonical FTP or web servers. Ideally, the
+canonical servers only mirror out to a first tier of mirrors, and all
+user access is to the mirrors. This allows Debian to better spread
+its bandwidth requirements over several servers and networks. Note
+that newer push mirroring techniques ensure that mirrors are as
+up-to-date as they can be.
+ <p>
+The main web page listing the available public FTP (and, usually,
+HTTP) servers can be found at <url id="&url-debian-mirrors;">. More
+information concerning Debian mirrors can be found at <url
+id="&url-debian-mirroring;">. This useful page includes information
+and tools which can be helpful if you are interested in setting up
+your own mirror, either for internal or public access.
+ <p>
+Note that mirrors are generally run by third-parties who are
+interested in helping Debian. As such, developers generally do not
+have accounts on these machines.
+
+
+ <sect id="other-machines">Other Debian developer machines
+ <p>
+There are other Debian machines which may be made available to you.
+You can use these for Debian-related purposes as you see fit. Please
+be kind to system administrators, and do not use up tons and tons of
+disk space, network bandwidth, or CPU without first getting the
+approval of the local maintainers. Usually these machines are run by
+volunteers. Generally, these machines are for porting activities.
+ <p>
+Aside from the servers mentioned in <ref id="server-machines">, there
+is a list of machines available to Debian developers at <url
+id="&url-devel-machines;">.
+
+
+
+ <sect id="archive">The Debian archive
+ <p>
+The &debian-formal; distribution consists of a lot of packages
+(<tt>.deb</tt>'s, currently around &number-of-pkgs;) and a few
+additional files (such documentation and installation disk images).
+ <p>
+Here is an example directory tree of a complete Debian archive:
+ <p>
+&sample-dist-dirtree;
+ <p>
+As you can see, the top-level directory contains two directories,
+<tt>dists/</tt> and <tt>pool/</tt>. The latter is a “pool” in which the
+packages actually are, and which is handled by the archive maintenance
+database and the accompanying programs. The former contains the
+distributions, <em>stable</em>, <em>testing</em> and <em>unstable</em>.
+Each of those distribution directories is divided in equivalent
+subdirectories purpose of which is equal, so we will only explain how it
+looks in stable. The <tt>Packages</tt> and <tt>Sources</tt> files in the
+distribution subdirectories can reference files in the <tt>pool/</tt>
+directory.
+ <p>
+<tt>dists/stable</tt> contains three directories, namely <em>main</em>,
+<em>contrib</em>, and <em>non-free</em>.
+ <p>
+In each of the areas, there is a directory with the source packages
+(<tt>source</tt>), a directory for each supported architecture
+(<tt>binary-i386</tt>, <tt>binary-m68k</tt>, etc.), and a directory
+for architecture independent packages (<tt>binary-all</tt>).
+ <p>
+The <em>main</em> area contains additional directories which holds
+the disk images and some essential pieces of documentation required
+for installing the Debian distribution on a specific architecture
+(<tt>disks-i386</tt>, <tt>disks-m68k</tt>, etc.).
+ <p>
+The <em>binary-*</em> and <em>source</em> directories are divided
+further into <em>subsections</em>.
+
+
+ <sect1>Sections
+ <p>
+The <em>main</em> section of the Debian archive is what makes up the
+<strong>official &debian-formal; distribution</strong>. The
+<em>main</em> section is official because it fully complies with all
+our guidelines. The other two sections do not, to different degrees;
+as such, they are <strong>not</strong> officially part of
+&debian-formal;.
+ <p>
+Every package in the main section must fully comply with the <url
+id="&url-dfsg;" name="Debian Free Software Guidelines"> (DFSG) and
+with all other policy requirements as described in the <url
+id="&url-debian-policy;" name="Debian Policy Manual">. The DFSG is
+our definition of “free software.” Check out the Debian Policy
+Manual for details.
+ <p>
+Packages in the <em>contrib</em> section have to comply with the DFSG,
+but may fail other requirements. For instance, they may depend on
+non-free packages.
+ <p>
+Packages which do not apply to the DFSG are placed in the
+<em>non-free</em> section. These packages are not considered as part
+of the Debian distribution, though we support their use, and we
+provide infrastructure (such as our bug-tracking system and mailing
+lists) for non-free software packages.
+ <p>
+The <url id="&url-debian-policy;" name="Debian Policy Manual">
+contains a more exact definition of the three sections. The above
+discussion is just an introduction.
+ <p>
+The separation of the three sections at the top-level of the archive
+is important for all people who want to distribute Debian, either via
+FTP servers on the Internet or on CD-ROMs: by distributing only the
+<em>main</em> and <em>contrib</em> sections, one can avoid any legal
+risks. Some packages in the <em>non-free</em> section do not allow
+commercial distribution, for example.
+ <p>
+On the other hand, a CD-ROM vendor could easily check the individual
+package licenses of the packages in <em>non-free</em> and include as
+many on the CD-ROMs as he's allowed to. (Since this varies greatly from
+vendor to vendor, this job can't be done by the Debian developers.)
+
+
+ <sect1>Architectures
+ <p>
+In the first days, the Linux kernel was only available for the Intel
+i386 (or greater) platforms, and so was Debian. But when Linux became
+more and more popular, the kernel was ported to other architectures,
+too.
+ <p>
+The Linux 2.0 kernel supports Intel x86, DEC Alpha, SPARC, Motorola
+680x0 (like Atari, Amiga and Macintoshes), MIPS, and PowerPC. The
+Linux 2.2 kernel supports even more architectures, including ARM and
+UltraSPARC. Since Linux supports these platforms, Debian decided that
+it should, too. Therefore, Debian has ports underway; in fact, we
+also have ports underway to non-Linux kernel. Aside from
+<em>i386</em> (our name for Intel x86), there is <em>m68k</em>,
+<em>alpha</em>, <em>powerpc</em>, <em>sparc</em>, <em>hurd-i386</em>,
+and <em>arm</em>, as of this writing.
+ <p>
+&debian-formal; 1.3 is only available as <em>i386</em>. Debian 2.0
+shipped for <em>i386</em> and <em>m68k</em> architectures. Debian 2.1
+ships for the <em>i386</em>, <em>m68k</em>, <em>alpha</em>, and
+<em>sparc</em> architectures. Debian 2.2 adds support for the
+<em>powerpc</em> and <em>arm</em> architectures.
+ <p>
+Information for developers or uses about the specific ports are
+available at the <url id="&url-debian-ports;" name="Debian Ports web
+pages">.
+
+
+ <sect1>Subsections
+ <p>
+The sections <em>main</em>, <em>contrib</em>, and <em>non-free</em>
+are split into <em>subsections</em> to simplify the installation
+process and the maintainance of the archive. Subsections are not
+formally defined, except perhaps the `base' subsection.
+Subsections simply exist to simplify the organization and browsing of
+available packages. Please check the current Debian distribution to
+see which sections are available.
+ <p>
+Note however that with the introduction of package pools (see the top-level
+<em>pool/</em> directory), the subsections in the form of subdirectories
+will eventually cease to exist. They will be kept in the packages' `Section'
+header fields, though.
+
+ <sect1>Packages
+ <p>
+There are two types of Debian packages, namely <em>source</em> and
+<em>binary</em> packages.
+ <p>
+Source packages consist of either two or three files: a <tt>.dsc</tt>
+file, and either a <tt>.tar.gz</tt> file or both an
+<tt>.orig.tar.gz</tt> and a <tt>.diff.gz</tt> file.
+ <p>
+If a package is developed specially for Debian and is not distributed
+outside of Debian, there is just one <tt>.tar.gz</tt> file which
+contains the sources of the program. If a package is distributed
+elsewhere too, the <tt>.orig.tar.gz</tt> file stores the so-called
+<em>upstream source code</em>, that is the source code that's
+distributed from the <em>upstream maintainer</em> (often the author of
+the software). In this case, the <tt>.diff.gz</tt> contains the
+changes made by the Debian maintainer.
+ <p>
+The <tt>.dsc</tt> lists all the files in the source package together
+with checksums (<prgn>md5sums</prgn>) and some additional info about
+the package (maintainer, version, etc.).
+
+
+ <sect1>Distribution directories
+ <p>
+The directory system described in the previous chapter is itself
+contained within <em>distribution directories</em>. Each
+distribution is actually contained in the <tt>pool</tt> directory in the
+top-level of the Debian archive itself.
+ <p>
+To summarize, the Debian archive has a root directory within an FTP
+server. For instance, at the mirror site,
+<ftpsite>ftp.us.debian.org</ftpsite>, the Debian archive itself is
+contained in <ftppath>/debian</ftppath>, which is a common location
+(another is <tt>/pub/debian</tt>).
+ <p>
+A distribution is comprised of Debian source and binary packages, and the
+respective <tt>Sources</tt> and <tt>Packages</tt> index files, containing
+the header information from all those packages. The former are kept in the
+<tt>pool/</tt> directory, while the latter are kept in the <tt>dists/</tt>
+directory of the archive (because of backwards compatibility).
+
+
+ <sect2 id="sec-dists">Stable, testing, and unstable
+ <p>
+There are always distributions called <em>stable</em> (residing in
+<tt>dists/stable</tt>), one called <em>testing</em> (residing in
+<tt>dists/testing</tt>), and one called <em>unstable</em> (residing in
+<tt>dists/unstable</tt>). This reflects the development process of the
+Debian project.
+ <p>
+Active development is done in the <em>unstable</em> distribution
+(that's why this distribution is sometimes called the <em>development
+distribution</em>). Every Debian developer can update his or her
+packages in this distribution at any time. Thus, the contents of this
+distribution change from day-to-day. Since no special effort is done
+to make sure everything in this distribution is working properly, it is
+sometimes literally unstable.
+ <p>
+Packages get copied from <em>unstable</em> to <em>testing</em> if they
+satisfy certain criteria. To get into <em>testing</em> distribution, a
+package needs to be in the archive for two weeks and not have any
+release critical bugs. After that period, it will propagate into
+<em>testing</em> as soon as anything it depends on is also added. This
+process is automatic. You can see some notes on this system as well
+as <tt>update_excuses</tt> (describing which packages are valid
+candidates, which are not, and why not) at <url
+id="&url-testing-maint;">.
+ <p>
+After a period of development, once the release manager deems fit, the
+<em>testing</em> distribution is frozen, meaning that the policies
+which control how packages move from <em>unstable</em> to testing are
+tightened. Packages which are too buggy are removed. No changes are
+allowed into <em>testing</em> except for bug fixes. After some time
+has elapsed, depending on progress, the <em>testing</em> distribution
+goes into a `deep freeze', when no changes are made to it except those
+needed for the installation system. This is called a “test cycle”,
+and it can last up to two weeks. There can be several test cycles,
+until the distribution is prepared for release, as decided by the
+release manager. At the end of the last test cycle, the
+<em>testing</em> distribution is renamed to <em>stable</em>,
+overriding the old <em>stable</em> distribution, which is removed at
+that time (although it can be found at <tt>&archive-host;</tt>).
+ <p>
+This development cycle is based on the assumption that the
+<em>unstable</em> distribution becomes <em>stable</em> after passing a
+period of being in <em>testing</em>. Even once a distribution is
+considered stable, a few bugs inevitably remain &mdash that's why the
+stable distribution is updated every now and then. However, these
+updates are tested very carefully and have to be introduced into the
+archive individually to reduce the risk of introducing new bugs. You
+can find proposed additions to <em>stable</em> in the
+<tt>proposed-updates</tt> directory. Those packages in
+<tt>proposed-updates</tt> that pass muster are periodically moved as a
+batch into the stable distribution and the revision level of the
+stable distribution is incremented (e.g., ‘3.0’ becomes ‘3.0r1’,
+‘2.2r4’ becomes ‘2.0r5’, and so forth).
+ <p>
+Note that development under <em>unstable</em> continues during the
+freeze period, since the <em>unstable</em> distribution remains in
+place in parallel with <em>testing</em>.
+
+ <sect2>Experimental
+ <p>
+The <em>experimental</em> distribution is a specialty distribution.
+It is not a full distribution in the same sense as `stable' and
+`unstable' 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 <em>unstable</em> distribution (but there is a reason to
+package it nevertheless). Users who download and install
+packages from <em>experimental</em> are expected to have been duly
+warned. In short, all bets are off for the <em>experimental</em>
+distribution.
+ <p>
+If there is a chance that the software could do grave damage to a system,
+it is likely to be better to put it into <em>experimental</em>.
+For instance, an experimental compressed file system should probably go
+into <em>experimental</em>.
+ <p>
+Whenever there is a new upstream version of a package that introduces new
+features but breaks a lot of old ones, it should either not be uploaded, or
+be uploaded to <em>experimental</em>. A new, beta, version of some software
+which uses completely different configuration can go into
+<em>experimental</em>, at the maintainer's discretion. If you are working
+on an incompatible or complex upgrade situation, you can also use
+<em>experimental</em> as a staging area, so that testers can get early
+access.
+ <p>
+Some experimental software can still go into <em>unstable</em>, with a few
+warnings in the description, but that isn't recommended because packages
+from <em>unstable</em> are expected to propagate to <em>testing</em> and
+thus to <em>stable</em>.
+ <p>
+New software which isn't likely to damage your system can go directly into
+<em>unstable</em>.
+ <p>
+An alternative to <em>experimental</em> is to use your personal web space
+on <tt>people.debian.org</tt> (<tt>klecker.debian.org</tt>).
+
+
+ <sect1 id="codenames">Release code names
+ <p>
+Every released Debian distribution has a <em>code name</em>: 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'; and Debian 3.0, `woody'. 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.
+ <p>
+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 is released, which would cause all FTP
+mirrors to re-retrieve the whole distribution (which is quite large).
+ <p>
+On the other hand, if we called the distribution directories
+<em>Debian-x.y</em> from the beginning, people would think that Debian
+release <em>x.y</em> is available. (This happened in the past, where a
+CD-ROM vendor built a Debian 1.0 CD-ROM based on a pre-1.0 development
+version. That's the reason why the first official Debian release was
+1.1, and not 1.0.)
+ <p>
+Thus, the names of the distribution directories in the archive are
+determined by their code names and not their release status (e.g.,
+`slink'). These names stay the same during the development period and
+after the release; symbolic links, which can be changed easily,
+indicate the currently released stable distribution. That's why the
+real distribution directories use the <em>code names</em>, while
+symbolic links for <em>stable</em>, <em>testing</em>, and
+<em>unstable</em> point to the appropriate release directories.
+
+
+ <chapt id="pkgs">Managing Packages