An Irishman was asked to describe the greatest invention in civilization. After thinking for a few moments, he said "The Dewar flask" (Thermos bottle to Yanks). "Really," said the interviewer, "and why is that?". "Well", says the Irishman, "she keeps the hot things hot, ana she keeps the cold things chilled". "Yes, yes," says the interviewer, "we all know that". "Aye," says the Irishman, "but how does she know?".

In the case of apt, one word: [link|http://www.debian.org/doc/debian-policy/|Policy]. Specifically: [link|http://www.debian.org/doc/debian-policy/ch-binary.html#s3.5|3.5 Dependencies]

\r\n

Every package must specify the dependency information about other packages that are required for the first to work correctly.

\r\n\r\n

For example, a dependency entry must be provided for any shared libraries required by a dynamically-linked executable binary in a package.

\r\n\r\n

Packages are not required to declare any dependencies they have on other packages which are marked Essential (see below), and should not do so unless they depend on a particular version of that package.

\r\n\r\n

Sometimes, a package requires another package to be installed and configured before it can be installed. In this case, you must specify a Pre-Depends entry for the package.

\r\n\r\n

You should not specify a Pre-Depends entry for a package before this has been discussed on the debian-devel mailing list and a consensus about doing that has been reached.

\r\n\r\n

The format of the package interrelationship control fields is described in [link|http://www.debian.org/doc/debian-policy/ch-relationships.html|Declaring relationships between packages, Chapter 7].

\r\n

Dependencies are specified as packages, not as files.

Packages which incorrectly specify their dependencies -- to the point of naming the wrong version of a package, or overspecifying the version (restricting to a narrower range than is actually allowable), is a serious bug. A package with a serious outstanding bug filed against it won't be included in the stable release (it can however be in the unstable release).

Package maintenance is described in the [link|http://www.debian.org/doc/maint-guide/|Debian New Maintainers' Guide]. The [link|http://www.debian.org/doc/maint-guide/ch-dreq.en.html|structure of the 'control' file] is covered here. Note that line 10 of the control file, as detailed, includes an automated first-pass population of the "Depends" field with an automated utility. As with many other aspects of Debian, there are automated tools to assist in build and QC practices (shlibs:Depends). This is typical of the general practice in Debian. There is a contract, policy guides, technical direction and tools, selection processes, social reinforcement, and open bugtracking, all of which contribute to the quality of the project as a whole.

\r\n\r\n
• [link|http://www.debian.org/social_contract|Debian Social Contract] specifies overall goals and committments of the project.
\r\n\r\n
• [link|http://www.debian.org/doc/debian-policy/|Debian Policy] states the rules under which package maintainers must operate.
\r\n\r\n
• The [link|http://www.debian.org/doc/developers-reference/|Debian Developer's Reference] and [link|http://www.debian.org/doc/maint-guide/index.en.html|Debian New Maintainer's Guide] provide detailed guidance and reference tools for maintainers.
\r\n\r\n
• Several tools and packages ([link|http://packages.debian.org/stable/utils/dpkg-dev.html|dpkg-dev],\r\n[link|http://packages.debian.org/stable/devel/dh-make-perl.html|dh-make],\r\n[link|http://packages.debian.org/stable/devel/debhelper.html|debhelper],\r\n[link|http://packages.debian.org/stable/devel/devscripts.html|devscripts], and others listed in [link|http://www.debian.org/doc/maint-guide/ch-start.en.html|DNMG -- Getting started The Right Way] automate parts of the build and packaging process.
\r\n\r\n
• Maintainers are selected through [link|http://www.debian.org/doc/developers-reference/ch-new-maintainer.en.html|an application and sponsorship process]. It's slow and thorough, but has been the cause of some friction.
\r\n\r\n
• Maintainers are required to participate in the [link|http://lists.debian.org/debian-devel/|debian-devel] mailing list. This is a high-traffic, high-signal list in which pretty much everything of significance to Debian is discussed.
\r\n\r\n
• The [link|http://bugs.debian.org/|Debian Bugtracking System] (BTS) tracks feedback and bugs (from wishlist to severe) on packages. It's open to anyone for submissions (which means that spam to the BTS itself is a significant problem) and review. Debian's bugs are open to all to see -- the project doesn't hide its problems.
\r\n\r\n

No wonder [link|http://www.debian.org/News/weekly/1999/14/|Neal Stephenson digs Debian]. The man is all about technology, social groups, tribe, and evolution.

The result is that Debian manages to keep a loose-knit organization of over 1,000 package maintainers, scattered around the globe, maintaining over 13,500 packages, in a distribution which manages a stable release every 1.5 - 2 years, with a very high level of quality.

Debian stable [link|http://lists.debian.org/debian-project/2003/debian-project-200304/msg00104.html|release dates]:

\r\n
• Debian GNU/Linux 0.93R6 Oct 26, 1995
\r\n
• Debian GNU/Linux 1.1 ``buzz'' Jun 17, 1996
\r\n
• Debian GNU/Linux 1.2 ``rex'' Dec 12, 1996
\r\n
• Debian GNU/Linux 1.3 ``bo'' Jun 5, 1997
\r\n
• Debian GNU/Linux 2.0 ``hamm'' Jul 24, 1998
\r\n
• Debian GNU/Linux 2.1 ``slink'' Mar 9, 1999
\r\n
• Debian GNU/Linux 2.2 ``potato'' Aug 15, 2000
\r\n
• Debian GNU/Linux 3.0 ``woody'' Jul 19, 2002
\r\n

That's the sort of thing [link|http://opensource.mit.edu/papers/omahony.pdf|you might even expect a Stanford Management Science and Engineering PhD candidate to write a thesis about].

So that's how Debian knows.

Edits: fixed links.