]>
Commit | Line | Data |
---|---|---|
7e1245f4 MT |
1 | = pakfire-deps(5) |
2 | ||
3 | == NAME | |
4 | pakfire-deps - Information about dependencies in Pakfire | |
5 | ||
6 | == DESCRIPTION | |
7 | This page describes how dependencies between packages are expressed in Pakfire. | |
8 | ||
9 | Pakfire has a versatile and powerful dependency solving mechanism that is based | |
10 | on a SAT solver which will always find the best solution in the dependency tree | |
11 | if one is available. It does that in very short time as well. | |
12 | ||
13 | In order to figure out a solution in the dependency graph, the algorithm has to | |
14 | be fed with a lot of information which is described in this document. | |
15 | ||
16 | == DEFINITIONS | |
17 | ||
18 | 'EVR':: | |
19 | Short for epoch, version and release. For example 1.0-42, or 1:47.11-1. | |
20 | ||
21 | 'Capability':: | |
22 | A name (e.g. `bash`) of a package with an optional operator and EVR. | |
23 | + | |
24 | For example: `bash = 5.2` or `bash >= 5.0` | |
25 | ||
26 | Dependencies are divided into two categories: Strong vs. weak dependencies | |
27 | ||
28 | Strong dependencies have to be fulfilled at all times, whereas weak dependencies | |
29 | can be optional and are being used to give "recommendations" to the solver and | |
30 | the user. | |
31 | ||
32 | == STRONG DEPENDENCIES | |
33 | ||
34 | 'Requires':: | |
35 | A list of dependencies that all have to be fulfilled in order to install this | |
36 | package. | |
37 | ||
38 | 'Provides':: | |
39 | A list of capabilities provided by this package. Requires of other packages | |
40 | are being matched against this list. | |
41 | ||
42 | 'Conflicts':: | |
43 | The package cannot be installed if one or more of capabilities on this list | |
44 | match. | |
45 | ||
46 | 'Obsoletes':: | |
47 | When this package is installed, all other packages that match any of the | |
48 | capabilities will be uninstalled. | |
49 | ||
50 | == WEAK DEPENDENCIES | |
51 | ||
52 | 'Recommends':: | |
53 | A weak version of 'Requires'. Packages that match will be installed, but | |
54 | ignored if they cannot be installed. | |
55 | ||
56 | 'Suggests':: | |
57 | Suggests are hints for the user, but not handled during dependency resolution. | |
58 | + | |
59 | "Customers who bought this also bought..." | |
60 | ||
61 | == REVERSE DEPENDENCIES | |
62 | ||
63 | 'Supplements':: | |
64 | A reverse version of 'Recommends'. This package will be installed if another | |
65 | package that provides a matching capability is being installed. | |
66 | ||
67 | 'Enhances':: | |
68 | A reverse version of 'Suggests'. | |
69 | ||
70 | == RELATIONS | |
71 | ||
72 | Package dependencies can be expressed in various ways. The most simple one is to | |
73 | list the name of another package. For example: `python3`. This will cause that | |
74 | a package that provides `python3` is being installed. | |
75 | ||
76 | You can use operators and EVRs to select a specific version: | |
77 | ||
78 | 'package = EVR':: | |
79 | The package must be exactly the given version. | |
80 | ||
81 | 'package >= EVR':: | |
82 | The package must be the given version or newer. | |
83 | ||
84 | 'package <= EVR':: | |
85 | The package can be up to and including this version. | |
86 | ||
87 | 'package > EVR':: | |
88 | The package must be newer than this version. | |
89 | ||
90 | 'package < EVR':: | |
91 | The package must be older than this version. | |
92 | ||
93 | 'package':: | |
94 | This package can be of any version. | |
95 | ||
96 | In addition to the version comparison operators, Pakfire supports boolean operators | |
97 | which are also called "Rich Dependencies". They have to be wrapped in brackets. | |
98 | ||
99 | '(package and package)':: | |
100 | Requires all operands to be true for the entire term to be true. | |
101 | + | |
102 | For example: `Conflicts: (foo and bar)` | |
103 | ||
104 | '(package or package)':: | |
105 | Requires at least one of the operands to be true. | |
106 | + | |
107 | For example: `Requires: (foo >= 3.2 or bar)` | |
108 | ||
109 | '(package if package)':: | |
110 | Requires the first operand to be fulfilled if the second is | |
111 | (reverse implication). | |
112 | + | |
113 | For example: `Recommends: (foo-feature if feature)` | |
114 | ||
115 | '(package if package else package)':: | |
116 | Same as above, but requires the third operand to be fulfilled if the second is not. | |
117 | + | |
118 | For example: `Requires: (foo-feature if feature else foo-other-feature)` | |
119 | ||
120 | '(package unless package)':: | |
121 | Requires the first operand to be fulfilled if the second is not | |
122 | (reverse negative implication). | |
123 | + | |
124 | For example: `Conflicts: (foo-feature unless feature)` | |
125 | ||
126 | '(package unless package else package)':: | |
127 | Same as above, but requires the third operand to be fulfulled if the second is. | |
128 | + | |
129 | For example: `Conflicts: (foo-feature1 unless feature2 else foo-feature2)` | |
130 | ||
131 | '(package with package)':: | |
132 | Requires all operands to be fulfilled by the same package for the term to be true. | |
133 | + | |
134 | For example: `Requires: (pkg-foo with pkg-bar)` | |
135 | ||
136 | '(package without package)':: | |
137 | Requires a single package that satisfies the first operand but not the second | |
138 | (set subtraction). | |
139 | + | |
140 | For example: `Requires: (pkg-foo without pkg-bar)` | |
141 | ||
142 | The 'if' operator cannot be used in the same context with 'or' and the 'unless' operator | |
143 | cannot be used in the same context with 'and'. | |
144 | ||
145 | Rich dependencies can be nested like so: | |
146 | ||
147 | * `Requires: (foo or bar or baz)` | |
148 | * `Requires: (foo or (bar and baz))` | |
149 | * `Requires: ((pkg1 with feature2) or (pkg2 without feature1))` | |
150 | ||
151 | == AUTHORS | |
152 | Michael Tremer |