pakfire-deps - Information about dependencies in Pakfire
This page describes how dependencies between packages are expressed in Pakfire.
Pakfire has a versatile and powerful dependency solving mechanism that is based on a SAT solver which will always find the best solution in the dependency tree if one is available. It does that in very short time as well.
In order to figure out a solution in the dependency graph, the algorithm has to be fed with a lot of information which is described in this document.
Short for epoch, version and release. For example 1.0-42, or 1:47.11-1.
A name (e.g. bash) of a package with an optional operator and EVR.
For example: bash = 5.2 or bash >= 5.0
Dependencies are divided into two categories: Strong vs. weak dependencies
Strong dependencies have to be fulfilled at all times, whereas weak dependencies can be optional and are being used to give "recommendations" to the solver and the user.
A list of dependencies that all have to be fulfilled in order to install this package.
A list of capabilities provided by this package. Requires of other packages are being matched against this list.
The package cannot be installed if one or more of capabilities on this list match.
When this package is installed, all other packages that match any of the capabilities will be uninstalled.
A weak version of Requires. Packages that match will be installed, but ignored if they cannot be installed.
Suggests are hints for the user, but not handled during dependency resolution.
"Customers who bought this also bought…"
A reverse version of Recommends. This package will be installed if another package that provides a matching capability is being installed.
A reverse version of Suggests.
Package dependencies can be expressed in various ways. The most simple one is to list the name of another package. For example: python3. This will cause that a package that provides python3 is being installed.
You can use operators and EVRs to select a specific version:
- package = EVR
The package must be exactly the given version.
- package >= EVR
The package must be the given version or newer.
- package ⇐ EVR
The package can be up to and including this version.
- package > EVR
The package must be newer than this version.
- package < EVR
The package must be older than this version.
This package can be of any version.
In addition to the version comparison operators, Pakfire supports boolean operators which are also called "Rich Dependencies". They have to be wrapped in brackets.
- (package and package)
Requires all operands to be true for the entire term to be true.
For example: Conflicts: (foo and bar)
- (package or package)
Requires at least one of the operands to be true.
For example: Requires: (foo >= 3.2 or bar)
- (package if package)
Requires the first operand to be fulfilled if the second is (reverse implication).
For example: Recommends: (foo-feature if feature)
- (package if package else package)
Same as above, but requires the third operand to be fulfilled if the second is not.
For example: Requires: (foo-feature if feature else foo-other-feature)
- (package unless package)
Requires the first operand to be fulfilled if the second is not (reverse negative implication).
For example: Conflicts: (foo-feature unless feature)
- (package unless package else package)
Same as above, but requires the third operand to be fulfulled if the second is.
For example: Conflicts: (foo-feature1 unless feature2 else foo-feature2)
- (package with package)
Requires all operands to be fulfilled by the same package for the term to be true.
For example: Requires: (pkg-foo with pkg-bar)
- (package without package)
Requires a single package that satisfies the first operand but not the second (set subtraction).
For example: Requires: (pkg-foo without pkg-bar)
The if operator cannot be used in the same context with or and the unless operator cannot be used in the same context with and.
Rich dependencies can be nested like so:
Requires: (foo or bar or baz)
Requires: (foo or (bar and baz))
Requires: ((pkg1 with feature2) or (pkg2 without feature1))