(debian-policy.info)Syntax of relationship fields

---

Next: Binary Dependencies - Depends Recommends Suggests Enhances Pre-Depends Up: Declaring relationships between packages

---

Enter node , (file) or (file)node

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 except for ‘Provides’ 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 Note: Version.

The relations allowed are ‘<<’, ‘<=’, ‘=’, ‘>=’ and ‘>>’ for strictly
earlier, earlier or equal, exactly equal, later or equal and strictly
later, respectively.  (2)

Whitespace may appear at any point in the version specification subject
to the rules in Note: 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:

     Package: mutt
     Version: 1.3.17-1
     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 Note:
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:

     Source: glibc
     Build-Depends-Indep: texinfo
     Build-Depends: kernel-headers-2.2.10 [!hurd-i386],
      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:

     Build-Depends:
      libluajit5.1-dev [i386 amd64 kfreebsd-i386 armel armhf powerpc mips],
      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:

     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:

     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 Note:
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:

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

   ---------- Footnotes ----------

   (1) While ‘Build-Depends’, ‘Build-Depends-Indep’ and
‘Build-Depends-Arch’ permit the use of alternative dependencies, these
are not normally used by the Debian autobuilders.  To avoid
inconsistency between repeated builds of a package, the autobuilders
will default to selecting the first alternative, after reducing any
architecture-specific restrictions for the build architecture in
question.  While this may limit the usefulness of alternatives in a
single release, they can still be used to provide flexibility in
building the same package across multiple distributions or releases,
where a particular dependency is met by differently named packages.

   (2) The relations ‘<’ and ‘>’ were previously allowed, but they were
confusingly defined to mean earlier/later or equal rather than strictly
earlier/later.  ‘dpkg’ still supports them with a warning, but they are
no longer allowed by Debian Policy.