The software that has been packaged for Debian GNU/Linux is available in one of several directory trees on each Debian mirror site.
The dists directory is short for "distributions", and it is the canonical way to access the currently available Debian releases (and pre-releases).
The pool directory contains the actual packages, see What's in the pool directory?, Section 5.11.
There are the following supplementary directories:
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).
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 sarge. This means that woody is the current stable distribution and sarge is the current testing distribution.
unstable is a permanent symbolic link to sid, as sid is always the unstable distribution (see What about "sid"?, Section 5.5).
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, slink for release 2.1 and potato for release 2.2.
So far they have been characters taken from the movie "Toy Story" by Pixar.
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 truly `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
.
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 :-)
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).
These packages all comply with the Debian Free Software
Guidelines
, and are all freely usable and distributable.
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).
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.
More information about the status of "testing" in general and the
individual packages is available at http://www.debian.org/devel/testing
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'.
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:
Please note that the actual binary packages for woody and subsequent releases 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.
See On what hardware architectures/systems does Debian GNU/Linux run?, Section 3.1 for more information.
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.
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.
Normally, you won't have to worry about any of this, as apt and probably dpkg-ftp (see How can I keep my Debian system current?, Section 8.2) will handle it seamlessly.
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.
The Debian GNU/Linux FAQ
version 3.0.2, 28 January 2003