(debian-policy.info)Binary Dependencies - Depends Recommends Suggests Enhances Pre-Depends
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’, ‘Breaks’ and ‘Conflicts’ control fields.
‘Breaks’ is described in Note: Packages which break other packages -
Breaks, and ‘Conflicts’ is described in Note: Conflicting binary
packages - Conflicts. The rest are described below.
These seven fields are used to declare a dependency relationship by one
package on another. Except for ‘Enhances’ and ‘Breaks’, they appear in
the depending (binary) package’s control file. (‘Enhances’ appears in
the recommending package’s control file, and ‘Breaks’ appears in the
version of depended-on package which causes the named package to break).
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 ‘apt-get’,
‘aptitude’, and ‘dselect’.)
Since ‘Depends’ only places requirements on the order in which packages
are configured, packages in an installation run are usually all unpacked
first and all configured later. (1)
If there is a circular dependency among packages being installed or
removed, installation or removal order honoring the dependency order is
impossible, requiring the dependency loop be broken at some point and
the dependency requirements violated for at least one package. Packages
involved in circular dependencies may not be able to rely on their
dependencies being configured before they themselves are configured,
depending on which side of the break of the circular dependency loop
they happen to be on. If one of the packages in the loop has no
‘postinst’ script, then the cycle will be broken at that package; this
ensures that all ‘postinst’ scripts are run with their dependencies
properly configured if this is possible. Otherwise the breaking point
is arbitrary. Packages should therefore avoid circular dependencies
where possible, particularly if they have ‘postinst’ scripts.
The meaning of the five dependency fields is as follows:
‘Depends’
This declares an absolute dependency. A package will not be
configured unless all of the packages listed in its ‘Depends’ field
have been correctly configured (unless there is a circular
dependency as described above).
The ‘Depends’ field should be used if the depended-on package is
required for the depending package to provide a significant amount
of functionality.
The ‘Depends’ field should also be used if the ‘postinst’ or
‘prerm’ scripts require the depended-on package to be unpacked or
configured in order to run. In the case of ‘postinst configure’,
the depended-on packages will be unpacked and configured first.
(If both packages are involved in a dependency loop, this might not
work as expected; see the explanation a few paragraphs back.) In
the case of ‘prerm’ or other ‘postinst’ actions, the package
dependencies will normally be at least unpacked, but they may be
only “Half-Installed” if a previous upgrade of the dependency
failed.
Finally, the ‘Depends’ field should be used if the depended-on
package is needed by the ‘postrm’ script to fully clean up after
the package removal. There is no guarantee that package
dependencies will be available when ‘postrm’ is run, but the
depended-on package is more likely to be available if the package
declares a dependency (particularly in the case of ‘postrm
remove’). The ‘postrm’ script must gracefully skip actions that
require a dependency if that dependency isn’t available.
‘Recommends’
This declares a strong, but not absolute, dependency.
The ‘Recommends’ field should list packages that would be found
together with this one in all but unusual installations.
‘Suggests’
This is used to declare that one package may be more useful with
one or more others. Using this field tells the packaging system
and the user that the listed packages are related to this one and
can perhaps enhance its usefulness, but that installing this one
without them is perfectly reasonable.
‘Enhances’
This field is similar to Suggests but works in the opposite
direction. It is used to declare that a package can enhance the
functionality of another package.
‘Pre-Depends’
This field is like ‘Depends’, except that it also forces ‘dpkg’ to
complete installation of the packages named before even starting
the installation of the package which declares the pre-dependency,
as follows:
When a package declaring a pre-dependency is about to be `unpacked'
the pre-dependency can be satisfied if the depended-on package is
either fully configured, `or even if' the depended-on package(s)
are only in the “Unpacked” or the “Half-Configured” state, provided
that they have been configured correctly at some point in the past
(and not removed or partially removed since). In this case, both
the previously-configured and currently “Unpacked” or
“Half-Configured” versions must satisfy any version clause in the
‘Pre-Depends’ field.
When the package declaring a pre-dependency is about to be
`configured', the pre-dependency will be treated as a normal
‘Depends’. It will be considered satisfied only if the depended-on
package has been correctly configured. However, unlike with
‘Depends’, ‘Pre-Depends’ does not permit circular dependencies to
be broken. If a circular dependency is encountered while
attempting to honor ‘Pre-Depends’, the installation will be
aborted.
‘Pre-Depends’ are also required if the ‘preinst’ script depends on
the named package. It is best to avoid this situation if possible.
‘Pre-Depends’ should be used sparingly, preferably only by packages
whose premature upgrade or installation would hamper the ability of
the system to continue with any upgrade that might be in progress.
You should not specify a ‘Pre-Depends’ entry for a package before
this has been discussed on the ‘debian-devel’ mailing list and a
consensus about doing that has been reached. See Note:
Dependencies.
When selecting which level of dependency to use you should consider how
important the depended-on package is to the functionality of the one
declaring the dependency. Some packages are composed of components of
varying degrees of importance. Such a package should list using
‘Depends’ the package(s) which are required by the more important
components. The other components’ requirements may be mentioned as
Suggestions or Recommendations, as appropriate to the components’
relative importance.
---------- Footnotes ----------
(1) This approach makes dependency resolution easier. If two
packages A and B are being upgraded, the installed package A depends on
exactly the installed package B, and the new package A depends on
exactly the new package B (a common situation when upgrading shared
libraries and their corresponding development packages), satisfying the
dependencies at every stage of the upgrade would be impossible. This
relaxed restriction means that both new packages can be unpacked
together and then configured in their dependency order.
automatically generated by info2www version 1.2.2.9