There are the following supplementary directories:
/tools/:
DOS utilities for creating boot disks, partitioning your disk drive,
compressing/decompressing files, and booting Linux.
/doc/:
The basic Debian documentation, such as the FAQ, the bug reporting system
instructions, etc.
/indices/:
The Maintainers file and the override files.
/project/:
mostly developer-only materials, such as:
project/experimental/:
This directory contains packages and tools which are still being developed, and
are still in the alpha testing stage. Users shouldn't be using packages from
here, because they can be dangerous and harmful even for most experienced
people.
project/orphaned/:
Packages that have been orphaned by their old maintainers, and withdrawn from
the distribution.
5.2 How many Debian distributions are there in the dists directory?
Normally there are three distributions, the "stable" distribution,
the "testing" distribution, and the "unstable"
distribution. Sometimes there is also a "frozen" distribution (see
What about "frozen"?, Section
5.4).
5.3 What are all those names like slink, potato, etc.?
They are just "codenames". When a Debian distribution is in the
development stage, it has no version number but a codename. The purpose of
these codenames is to make easier the mirroring of the Debian distributions (if
a real directory like unstable suddenly changed its name to
stable, a lot of stuff would have to be needlessly downloaded
again).
Currently, stable is a symbolic link to woody (i.e.
Debian GNU/Linux 3.0) and testing is a symbolic link to
woody+1. This means that woody is the current stable
distribution and woody+1 is the current testing distribution.
Note: the woody+1 name was not decided at the time of writing this, please
check the nearest up to date mirror for exact data.
unstable is a permanent symbolic link to sid, as
sid is always the unstable distribution (see What about "sid"?, Section 5.5).
5.3.1 Which other codenames have been used in the past?
Other codenames that have been already used are: buzz for release
1.1, rex for release 1.2, bo for releases 1.3.x,
hamm for release 2.0, and slink for release 2.1.
5.3.2 Where do these codenames come from?
So far they have been characters taken from the movie "Toy Story" by
Pixar.
buzz (Buzz Lightyear) was the spaceman,
rex was the tyrannosaurus,
bo (Bo Peep) was the girl who took care of the sheep,
hamm was the piggy bank,
slink (Slinky Dog) was the toy dog,
potato was, of course, Mr. Potato,
woody was the cowboy.
5.4 What about "frozen"?
When the "testing" distribution is mature enough, the release manager
starts `freezing' it. The normal propagation delays are increased to ensure
that as little as possible new bugs from "unstable" enter
"testing". After a while, the "testing" distribution
becomes truely `frozen'. This means that all new packages that are to
propagate to the "testing" are held back, unless they include
release-critical bug fixes. The "testing" distribution can also
remain in such a deep freeze during the so-called `test cycles', when the
release is imminent.
We keep a record of bugs in the "testing" distribution that can hold
off a package from being released, or bugs that can hold back the whole
release. Once that bug count lowers to maximum acceptable values, the frozen
"testing" distribution is declared "stable" and released
with a version number.
With each new release, the previous "stable" distribution becomes
obsolete and moves to the archive. For more information please see Debian archive.
5.5 What about "sid"?
sid or unstable is the place where most of the packages are
initially uploaded. It will never be released directly, because packages which
are to be released will first have to be included in testing, in order
to be released in stable later on. sid contains packages for both
released and unreleased architectures.
The name "sid" also comes from the "Toy Story" animated
motion picture: Sid was the boy next door who destroyed toys :-)
5.5.1 Historical notes about "sid"
When the present-day sid did not exist, the FTP site organization had one major
flaw: there was an assumption that when an architecture is created in the
current unstable, it will be released when that distribution becomes the new
stable. For many architectures that isn't the case, with the result that those
directories had to be moved at release time. This was impractical because the
move would chew up lots of bandwidth.
The archive administrators worked around this problem for several years by
placing binaries for unreleased architectures in a special directory called
"sid". For those architectures not yet released, the first time they
were released there was a link from the current stable to sid, and from then on
they were created inside the unstable tree as normal. This layout was somewhat
confusing to users.
With the advent of package pools (see What's in the pool directory?,
Section 5.11), binary packages began to be stored in a canonical location
in the pool, regardless of the distribution, so releasing a distribution no
longer causes large bandwidth consumption on the mirrors (there is, however, a
lot of gradual bandwidth consumption throughout the development process).
5.6 What does the stable directory contain?
stable/main/: This directory contains the packages which formally constitute
the most recent release of the Debian GNU/Linux system.
stable/non-free/: This directory contains packages distribution of which is
restricted in a way that requires that distributors take careful account of the
specified copyright requirements.
For example, some packages have licenses which prohibit commercial
distribution. Others can be redistributed but are in fact shareware and not
freeware. The licenses of each of these packages must be studied, and possibly
negotiated, before the packages are included in any redistribution (e.g., in a
CD-ROM).
stable/contrib/: This directory contains packages which are DFSG-free and
freely distributable themselves, but somehow depend on a package that
is not freely distributable and thus available only in the non-free
section.
5.7 What does the testing directory contain?
Packages are installed into the `testing' directory after they have undergone
some degree of testing in unstable. They must be in sync on all architectures
where they have been built and mustn't have dependencies that make them
uninstallable; they also have to have fewer release-critical bugs than the
versions currently in testing. This way, we hope that `testing' is always
close to being a release candidate.
5.8 What does the unstable directory contain?
The `unstable' directory contains a snapshot of the current development system.
Users are welcome to use and test these packages, but are warned about their
state of readiness. The advantage of using the unstable distribution is that
you are always up-to-date with the latest in GNU/Linux software industry, but
if it breaks: you get to keep both parts :-)
There are also main, contrib and non-free subdirectories in `unstable',
separated on the same criteria as in `stable'.
5.9 What are all those directories inside dists/stable/main?
Within each of the major directory trees (dists/stable/main,
dists/stable/contrib, dists/stable/non-free, and
dists/unstable/main/, etc.), the binary packages reside in
subdirectories whose names indicate the chip architecture for which they were
compiled:
binary-all/, for packages which are architecture-independent. These include,
for example, Perl scripts, or pure documentation.
binary-i386/, for packages which execute on 80x86 PC machines.
binary-m68k/, for packages which execute on machines based on one of the
Motorola 680x0 processors. Currently this is done mainly for Atari and Amiga
computers, and also for some VME based industry standard boards.
binary-sparc/, for packages which execute on Sun SPARCStations.
binary-alpha/, for packages which execute on DEC Alpha machines.
binary-powerpc/, for packages which execute on PowerPC machines.
binary-arm/, for packages which execute on ARM machines.
Please note that the actual binary packages for testing and
unstable no longer reside in these directories, but in the top level
pool directory. The index files (Packages and Packages.gz) have
been kept, though, for backwards compatibility.
Source code is included for everything in the Debian system. Moreover, the
license terms of most programs in the system require that source code
be distributed along with the programs, or that an offer to provide the source
code accompany the programs.
Normally the source code is distributed in the "source" directories,
which are parallel to all the architecture-specific binary directories, or more
recently in the pool directory (see What's in the pool directory?,
Section 5.11). To retrieve the source code without having to be familiar
with the structure of the FTP archive, try a command like apt-get source
mypackagename.
Some packages are only distributed as source code due to the restrictions in
their licenses. Notably, one such package is pine, see Where is pine?, Section 4.10 for more
information.
Source code may or may not be available for packages in the "contrib"
and "non-free" directories, which are not formally part of the Debian
system.
5.11 What's in the pool directory?
Historically, packages were kept in the subdirectory of dists
corresponding to which distribution contained them. This turned out to cause
various problems, such as large bandwidth consumption on mirrors when major
changes were made.
Packages are now kept in a large `pool', structured according to the name of
the source package. To make this manageable, the pool is subdivided by section
(`main', `contrib' and `non-free') and by the first letter of the source
package name. These directories contain several files: the binary packages for
each architecture, and the source packages from which the binary packages were
generated.
You can find out where each package is placed by executing a command like
apt-cache showsrc mypackagename and looking at the `Directory:'
line. For example, the apache packages are stored in
pool/main/a/apache/. Since there are so many lib*
packages, these are treated specially: for instance, libpaper packages are
stored in pool/main/libp/libpaper/.
The dists directories are still used for the index files used by
programs like apt. Also, at the time of writing, older
distributions have not been converted to use pools so you'll see paths
containing distributions such as potato or woody in the Filename header field.
After a developer uploads a package, it stays for a short while in the
"incoming" directory before it is checked that it's genuine and
allowed into the archive.
Usually nobody should install things from this place. However, in some rare
cases of emergency, the incoming directory is available at http://incoming.debian.org/. You
can manually fetch packages, check the GPG signature and MD5sums in the
.changes and .dsc files, and then install them.