7.1. Syntax of relationship fields

These fields all have a uniform syntax. They are a list of package names separated by commas.

In the Depends, Recommends, Suggests, Pre-Depends, Build-Depends, Build-Depends-Indep and Build-Depends-Arch control fields of the package, which declare dependencies on other packages, the package names listed may also include lists of alternative package names, separated by vertical bar (pipe) symbols |. In such a case, that part of the dependency can be satisfied by any one of the alternative packages. 1

All of the fields may restrict their applicability to particular versions of each named package. This is done in parentheses after each individual package name; the parentheses should contain a relation from the list below followed by a version number, in the format described in Version.

The relations allowed are <<, <=, =, >= and >> for strictly earlier, earlier or equal, exactly equal, later or equal and strictly later, respectively. The exception is the Provides field, for which only = is allowed. 2

Whitespace may appear at any point in the version specification subject to the rules in Syntax of control files, and must appear where it’s necessary to disambiguate; it is not otherwise significant. All of the relationship fields can only be folded in source package control files. For consistency and in case of future changes to dpkg it is recommended that a single space be used after a version relationship and before a version number; it is also conventional to put a single space after each comma, on either side of each vertical bar, and before each open parenthesis. When opening a continuation line in a relationship field, it is conventional to do so after a comma and before the space following that comma.

For example, a list of dependencies might appear as:

  1. Package: mutt
  2. Version: 1.3.17-1
  3. Depends: libc6 (>= 2.2.1), default-mta | mail-transport-agent

Relationships may be restricted to a certain set of architectures. This is indicated in brackets after each individual package name and the optional version specification. The brackets enclose a non-empty list of Debian architecture names in the format described in Architecture specification strings, 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 while others aren’t.)

For build relationship fields (Build-Depends, Build-Depends-Indep, Build-Depends-Arch, Build-Conflicts, Build-Conflicts-Indep and Build-Conflicts-Arch), if the current Debian 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:

  1. Source: glibc
  2. Build-Depends-Indep: texinfo
  3. Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
  4.  hurd-dev [hurd-i386], gnumach-dev [hurd-i386]

requires kernel-headers-2.2.10 on all architectures other than hurd-i386 and requires hurd-dev and gnumach-dev only on hurd-i386. Here is another example showing multiple architectures separated by spaces:

  1. Build-Depends:
  2.  libluajit5.1-dev [i386 amd64 kfreebsd-i386 armel armhf powerpc mips],
  3.  liblua5.1-dev [hurd-i386 ia64 kfreebsd-amd64 s390x sparc],

For binary relationship fields and the Built-Using field, the architecture restriction syntax is only supported in the source package control file debian/control. When the corresponding binary package control file is generated, the relationship will either be omitted or included without the architecture restriction based on the architecture of the binary package. This means that architecture restrictions must not be used in binary relationship fields for architecture-independent packages (Architecture: all).

For example:

  1. Depends: foo [i386], bar [amd64]

becomes Depends: foo when the package is built on the i386 architecture, Depends: bar when the package is built on the amd64 architecture, and omitted entirely in binary packages built on all other architectures.

If the architecture-restricted dependency is part of a set of alternatives using |, that alternative is ignored completely on architectures that do not match the restriction. For example:

  1. Build-Depends: foo [!i386] | bar [!amd64]

is equivalent to bar on the i386 architecture, to foo on the amd64 architecture, and to foo | bar on all other architectures.

Relationships may also be restricted to a certain set of architectures using architecture wildcards in the format described in Architecture wildcards. The syntax for declaring such restrictions is the same as declaring restrictions using a certain set of architectures without architecture wildcards. For example:

  1. Build-Depends: foo [linux-any], bar [any-i386], baz [!linux-any]

is equivalent to foo on architectures using the Linux kernel and any cpu, bar on architectures using any kernel and an i386 cpu, and baz on any architecture using a kernel other than Linux.

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