Supported Dependencies

All Resolvables are treated alike during dependency resolution. There is no semantical difference between different kinds of Resolvables.

This page describes the possible dependencies a Resolvable can express and their semantics.

It is heavily based on rpm (for the strong dependencies) and debian (for the weak dependencies).
The reverse dependencies were made on suggestion by Michael Schroeder.

If in doubt, look at RPM and Debian.

Definition of words

Edition: The combination of epoch, version, and release. Just like RPM, i.e. 1.0-42 or 1:1.47-11.
Capability: A name with an optional operator and an edition, i.e. foo, foo = 1.0-42, bar > 1.47.
Dependency: A combination of capabilities and a what (i.e. Requires, Provides, ...).

Strong dependencies

Requires: An absolute dependencies. All requirements must be fulfilled.
Provides: Capabilities this resolvable provides. They can be used to match Requires from others.
Every Resolvable has a self-provide by default, its own name and edition, i.e. package bar-1.42-1 provides capability bar = 1.42-1.
Conflicts: This Resolvable cannot be installed if another Resolvable is installed and provides matching capabilities.
Obsoletes: When this Resolvable is installed, it will uninstall any other Resolvable with a matching name.

Weak dependencies

Recommends: A weak Requires. A best-try approach is made to fulfill Recommends but they are silently dropped if no match is possible.
Suggests: Suggests are just hints for an application and not handled during dependency resolution.
Kind of Amazon-style customers who bought this also looked at that

Conditional dependencies

Freshens: Freshens define the relationship between an uninstalled Resolvable and an installed one. If an uninstalled resolvable defines a freshen dependency, it is only considered for installation if an installed resolvable matches. Its primary use is for Patches which express via freshen when they are to be considered.

Reverse dependencies

Unlike the above mentioned dependencies, which are kind-of top-down, the following dependencies work the other way around. Read on.

Supplements: A reverse recommends. This resolvable will be installed if this capability is provided by an installed resolvable. The dependency resolver will install it. Uninstalling it is silently accepted.
Enhances: A reverse suggests. This resolvable can be installed if this capability is provided by an installed resolvable. Its just a hint for an application. I.e. SuSEplugger can suggest packages for installation if a specific hardware is found.

Special libsolv resolvables

Note: rpm 4.14 and newer support boolean dependencies. These obsolete the legacy libsolv syntax described below; spec-cleaner will replace packageand and remove otherproviders constructs. libsolv knows of two special cases:

packageand(A:B). Usually used together with reverse dependencies, e.g. Supplements: packageand(A:B) proposes T only if both A and B are installed/to be installed.
otherproviders(S). Usually used together with Provides/Conflicts, e.g. Provides: smtp_daemon, Conflicts: otherproviders(smtp_daemon). This exists so that a package does not end up conflicting with itself due to a resolvable it itself provides. This keyword is not required with current RPM releases and as such just use Conflicts: name to achieve the same result.

RPM (4.13) itself does not know about the special meaning and considers them normal resolvables. In practice, these get ignored, because there is no realistic package that would have a "Provides: packageand(A:B)" or "Provides: otherproviders(S)".

Libzypp/Dependencies

Contents