Dependency

A dependency is a package that is required for another to function. dpkg and apt have this concept, and that is what allows them to make sure that your system will be functional by pulling in required packages when you install a package.

There are different types of dependency:

• Build dependencies. These specify that another package is required for this one to build.
• Dependencies. These are packages that are required to be installed for this one to work.
• Recommeds. These are packages that you would need installed on your system for this one to work properly in most cases. It is supposed to be for packages that are not absolutely required (the package still does something), but that it would be rare to not install them with this package. By default aptitude installs these as well as the dependencies when you install a package, but apt does not.
• Suggests. These are packages that complement the package, or add some functionality to it, but you can get by perfectly well without.
• Pre-depends. These are a packages that must be fully installed before you try and install this package. They are rare, and should be avoided where possible. See the relevant section of DebianPolicy on the matter.

There is also the related concept of Conflicts.

There is often debate about whether a given package belongs in Depends, Reccomends or Suggests. It is usually up to the maintainer where they put it. Some people tend to make dependencies more firm (closer to the Depends relationship), than they have to be, so that there is more chance of the packages being installed together and the user getting the enhanced functionality without trying. It also attempts to avoid BugReports where the problem is that users haven't got the required package as it was not installed for them. Other people go the other way and make the dependecies looser, arguing that pulling in a lot of unwanted packages wastes space, and it should be left to the user to decide whether they require something or not.

There are several ways in which packages can be specified in one of these fields

• Versioned Dependency. This is where not just any version of a package will do. It is possible to specify certain versions of a package using equalities and inequalities, e.g. foo (>= 4.0).
• Architecture specific dependencies. These make a dependency specific to an Architecture, or allow the dependency to be ignored on an arch. This could be the case when linking against a library is only needed on some architectures, or a certain arch doesn't have a package, and so it can't be listed as a Suggests. This are specified using the names in square brackets with exclamation marks denoting a negation, e.g. foo [i386], bar [!amd64].
• Alternative dependencies. These specify that anyone of a group of packages may satisfy the dependency. The usual behaviour is to specify dependencies spearated by commas (,), which specifies that both must be specified, but when separated by a pipe symbol (|) either of the packages being installed will satisfy the dependency. This is particularly useful with ?VirtualPackages, where a default can be specified first, and the virtual as an alternative. This use is especially important for build dependencies, as you cannot build-depend on a virtual package, but this use allows you to get around that somewhat. e.g. foo | bar.