Each package comes with a list of its own dependencies. For debs, which Ubuntu uses, you can do:-
[andys@daedalus ~]$ apt-cache depends git-core
git-core
Depends: git
The dependencies for a package are specified when the package is built. Some of them are specified manually by the package maintainer (the person who's responsible for building the package), and some are automatically determined when the package is built. If you download a Debian source package, and look in the debian/control
file, you'll see a number of lines like Depends:
, Conflicts:
, Replaces:
, etc.
So, back to the example - git-core
depends on only one package, which is git
. git
is probably a metapackage of some sort, which in turn has a whole raft of dependencies, to make sure all the packages neccessary to run git are installed - not just to satisfy the dependencies of one package. If we look at the git
package:-
[andys@daedalus ~]$ apt-cache depends git
git
Depends: libc6
Depends: libcurl3-gnutls
<...snip...>
Suggests: git-cvs
Suggests: git-svn
Suggests: git-email
<...snip...>
Recommends: rsync
<...snip...>
Conflicts: git-core
<...snip...>
Breaks: stgit
Breaks: stgit-contrib
Replaces: <cogito>
Replaces: git-core
...you'll see that git
itself has further dependencies. To complicate things further, there's different kinds of dependency other than just requiring another package to be installed...
- Conflicts - this package conflicts with another package, and you probably won't be able to install the conflicting package without uninstalling this one, and vice versa. In this case,
git
conflicts with git-core
. On my box here, the git-core
package is marked as obsolete, which is probably why this is listed here.
- Breaks - this package breaks another package, and installing it - although perhaps not requiring you to uninstall the package that will be broken - will cause problems with the software installed by that package. Again, looking at our example, the
stgit
and stgit-contrib
packages will be considered broken once git
is installed.
- Replaces - this package replaces another package, meaning that the other package is obsolete and can probably be uninstalled. The
git-core
package shows up again here.
There are also 'soft' dependency types, such as Recommends and Suggests, which aren't required by the package you're installing, but are recommended or suggested, as the name suggests. Once again, looking at the example, the suggested and recommended packages are add-ons to git, or tools not directly related that will make using it easier.
Putting all this together, the package manager you use will start off with the package (or packages) you've asked it to install, and will look up the dependencies for it, and then any dependencies for those packages, and so on. It will also check for packages which conflict, break or replace the requested packages or their dependencies. Once it's happy that it's found a way it can satisfy your original request, it'll then go ahead with the install.
Different package managers have different ways of doing this dependency resolution. apt-get
, aptitude
and dselect
, for example, all essentially do the same thing but the way they make their decision differs. You may find that aptitude
and dselect
will happily present you with a way to install a package whereas apt-get
can't.
If you're interested in knowing more about Debian packages, have a look at the Debian New Maintainers' Guide, which goes over some of the guts of debs.