Chapter 7. Declaring relationships between packages

46

All fields that specify build time relationships (

Build Depends

,

Build Depends Indep

,

Build Conflicts

and

Build Conflicts Indep

) may be restricted to a certain set of ar 

chitectures. This is indicated in brackets after each individual package name and the optional

version specification. The brackets enclose a list of Debian architecture names separated by

whitespace. Exclamation marks may be prepended to each of the names. (It is not permitted

for some names to be prepended with exclamation marks and others not.) If the current De 

bian host architecture is not in this list and there are no exclamation marks in the list, or it is

in the list with a prepended exclamation mark, the package name and the associated version

specification are ignored completely for the purposes of defining the relationships.

For example:

Source: glibc

Build Depends Indep: texinfo

Build Depends: kernel headers 2.2.10 [!hurd i386],

hurd dev [hurd i386], gnumach dev [hurd i386]

Note that the binary package relationship fields such as

Depends

appear in one of the

binary package sections of the control file, whereas the build time relationships such as

Build Depends

appear in the source package section of the control file (which is the first

section).

7.2 Binary Dependencies  

Depends

,

Recommends

,

Suggests

,

Enhances

,

Pre Depends

Packages can declare in their control file that they have certain relationships to other packages

  for example, that they may not be installed at the same time as certain other packages, and/or

that they depend on the presence of others.

This is done using the

Depends

,

Pre Depends

,

Recommends

,

Suggests

,

Enhances

and

Conflicts

control file fields.

These six fields are used to declare a dependency relationship by one package on another. Ex 

cept for

Enhances

, they appear in the depending (binary) package's control file. (

Enhances

appears in the recommending package's control file.)

A

Depends

field takes effect only when a package is to be configured. It does not prevent a

package being on the system in an unconfigured state while its dependencies are unsatisfied,

and it is possible to replace a package whose dependencies are satisfied and which is properly

installed with a different version whose dependencies are not and cannot be satisfied; when

this is done the depending package will be left unconfigured (since attempts to configure it

will give errors) and will not function properly. If it is necessary, a

Pre Depends

field can be

used, which has a partial effect even when a package is being unpacked, as explained in detail

below. (The other three dependency fields,

Recommends

,

Suggests

and

Enhances

, are only

used by the various front ends to

dpkg

such as

dselect

.)