# The Debian archives

## How many Debian distributions are there?

There are three major distributions: the "stable" distribution, the "testing" distribution, and the "unstable" distribution. The "testing" distribution is sometimes "frozen" (see frozen). Next to these, there is the "oldstable" distribution (that's just the one from before "stable"), and the "experimental" distribution.

Experimental is used for packages which are still being developed, and with a high risk of breaking your system. It's used by developers who'd like to study and test bleeding edge software. Users shouldn't be using packages from there, because they can be dangerous and harmful even for the most experienced people.

See choosing for help when choosing a Debian distribution.

## What are all those names like etch, lenny, 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 `&releasename;` (i.e. &debian; &release;) and `testing` is a symbolic link to `&nextreleasename;`. This means that `&releasename;` is the current stable distribution and `&nextreleasename;` is the current testing distribution.

`unstable` is a permanent symbolic link to `sid`, as `sid` is always the unstable distribution (see sid).

### Which other codenames have been used in the past?

Aside `&releasename;` and `&nextreleasename;`, 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, `potato` for release 2.2, `woody` for release 3.0, `sarge` for release 3.1, `etch` for release 4.0, `lenny` for release 5.0, `squeeze` for release 6.0, `wheezy` for release 7, `jessie` for release 8, `stretch` for release 9, `buster` for release 10, `bullseye` for release 11, `bookworm` for release 12.

### Where do these codenames come from?

So far they have been characters taken from the "Toy Story" movies by Pixar.

- buzz (Debian 1.1) was the spaceman Buzz Lightyear,

- rex (Debian 1.2) was the tyrannosaurus,

- bo (Debian 1.3) was Bo Peep, the girl who took care of the sheep,

- hamm (Debian 2.0) was the piggy bank,

- slink (Debian 2.1) was Slinky Dog, the toy dog,

- potato (Debian 2.2) was, of course, Mr. Potato,

- woody (Debian 3.0) was the cowboy,

- sarge (Debian 3.1) was the sergeant of the Green Plastic Army Men,

- etch (Debian 4.0) was the toy whiteboard (Etch-a-Sketch),

- lenny (Debian 5.0) was the toy binoculars,

- squeeze (Debian 6) was the name of the three-eyed aliens,

- wheezy (Debian 7) was the rubber toy penguin with a red bow tie,

- jessie (Debian 8) was the yodeling cowgirl,

- stretch (Debian 9) was the rubber toy octopus with suckers on her eight long arms.

- buster (Debian 10) was Andy's pet dog.

- bullseye (Debian 11) was Woody's wooden toyhorse.

- bookworm (Debian 12) was a green toy worm with a built-in flashlight who loves reading books.

- trixie (Debian 13) was a blue plastic triceratops.

- sid was the evil neighbor kid next door who broke all toys.

The decision of using Toy Story names was made by Bruce Perens who was, at the time, the Debian Project Leader and was working also at Pixar, the company that produced the movies.

## 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 :-)

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 pools), 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).

## What does the stable directory contain?

- stable/main/: This directory contains the packages which formally constitute the most recent release of the &debian; system.

  These packages all comply with the Debian Free Software Guidelines, and are all freely usable and distributable.

- 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 free software. 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.

## What does the testing distribution 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 need to have fewer release-critical bugs than the versions currently in unstable. 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 .

### What about "testing"? How is it "frozen"?

When the "testing" distribution is mature enough, the release manager starts "freezing" it. The normal propagation delays are increased to ensure that as few new bugs as possible 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.

When a "testing" release becomes "frozen", "unstable" tends to partially freeze as well. This is because developers are reluctant to upload radically new software to unstable, in case the frozen software in testing needs minor updates and to fix release critical bugs which keep testing from becoming "stable".

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. For details, please see current testing release information.

Once that bug count lowers to maximum acceptable values, the frozen "testing" distribution is declared "stable" and released with a version number.

The most important bug count is the "Release Critical" bug count, which can be followed in the Release-critical bug status page. A common release goal is NoRCBugs which means that the distribution should not have any bugs of severity critical, grave or serious. The full list of issues considered critical can be found in the RC policy document.

With each new release, the previous "stable" distribution becomes obsolete and moves to the archive. For more information please see Debian archive.

## What does the unstable distribution 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".

## What are all those directories at the Debian archives?

The software that has been packaged for &debian; 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 pools.

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 this FAQ, the bug reporting system instructions, etc.

/indices/:

- various indices of the site (the Maintainers file and the override files).

/project/:

- mostly developer-only materials and some miscellaneous files.

## 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.

, there are three sets of subdirectories containing index files.

There's one set of `binary-`something`` subdirectories which contain index files for binary packages of each available computer architecture, for example `binary-i386` for packages which execute on Intel x86 PC machines or `binary-sparc` for packages which execute on Sun SPARCStations.

The complete list of available architectures for each release is available at the release's web page. For the current release, please see arches.

The index files in binary-* are called Packages(.gz, .bz2) and they include a summary of each binary package that is included in that distribution. The actual binary packages reside in the top level `pool` directory.

Furthermore, there's a subdirectory called source/ which contains index files for source packages included in the distribution. The index file is called Sources(.gz, .bz2).

Last but not least, there's a set of subdirectories meant for the installation system index files, they are at `debian-installer/binary-`architecture``.

## Where is the source code?

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.

The source code is distributed in the `pool` directory (see pools) together with all the architecture-specific binary directories. To retrieve the source code without having to be familiar with the structure of the archive, try a command like `apt-get source mypackagename`.

Due to restrictions in their licenses, source code may or may not be available for packages in the "contrib" and "non-free" areas, which are not formally part of the Debian system. In some cases only sourceless "binary blobs" can be distributed (see for instance `firmware-misc-nonfree`); in other cases the license prohibits the distribution of prebuilt binaries, but does allow packages of source code which users can compile locally (see `broadcom-sta-dkms`).

## What's in the `pool` directory?

Packages are 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/`.

Additionally, since there are so many `lib*` packages, these are treated specially: for instance, libpaper packages are stored in `pool/main/libp/libpaper/`.

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. This was fixed with the introduction of the package pool.

The `dists` directories are still used for the index files used by programs like `apt`.

## What is "incoming"?

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 . You can manually fetch packages, check the GPG signature and MD5sums in the .changes and .dsc files, and then install them.

## Where can I find old packages of previous releases?

Old releases are removed from the main archive and mirrors, which only keep the content of the releases up to "oldstable" (the stable release before the current one). If you are interested in obtaining older versions of packages, go to .

The snapshot archive is a wayback machine that allows access to old packages based on dates and version numbers. It consists of all past and current packages the Debian archive provides. It provides a valuable valuable resource for tracking down when regressions were introduced, or for providing a specific environment that a particular application may require to run. The snapshot archive is accessible like any normal apt repository, allowing it to be easily used by all.

## How do I set up my own apt-able repository?

If you have built some private Debian packages which you'd like to install using the standard Debian package management tools, you can set up your own apt-able package archive. This is also useful if you'd like to share your Debian packages while these are not distributed by the Debian project. Instructions on how to do this are given on the Debian Wiki.