aboutsummaryrefslogtreecommitdiff
blob: da5153db3ff562bfbafba089fdaea0e2a92a4717 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
<?xml version="1.0"?>
<guide self="general-concepts/dependencies/">
<chapter>
<title>Dependencies</title>

<body>

<p>
  Automatic dependency resolution is one of the most useful features provided by
  <c>emerge</c>.
</p>

<section>
<title>Build Dependencies</title>
<body>

<p>
The <c>DEPEND</c> ebuild variable should specify any dependencies which are
required to unpack, patch, compile or install the package (but see
`Implicit System Dependency`_ for exemptions).
</p>

</body>
</section>

<section>
<title>Runtime Dependencies</title>
<body>

<p>
The <c>RDEPEND</c> ebuild variable should specify any dependencies which are
required at runtime. This includes libraries (when dynamically linked), any data
packages and (for interpreted languages) the relevant interpreter. If this
variable is not specified, it defaults to the value of <c>DEPEND</c>.
</p>

<p>
Note that when installing from a binary package, only <c>RDEPEND</c> will be
checked. It is therefore necessary to include items even if they are also listed
in <c>DEPEND</c>.
</p>

<p>
Items which are in <c>RDEPEND</c> but not <c>DEPEND</c> could <e>in theory</e> be merged
<e>after</e> the target package. Portage does not currently do this.
</p>

</body>
</section>

<section>
<title>Post-Merge Dependencies</title>
<body>

<p>
The <c>PDEPEND</c> variable specifies dependencies which must be merged <e>after</e> the
package. This is sometimes used for plugins which have a dependency upon the
package being merged. Generally <c>PDEPEND</c> should be avoided in favour of
<c>RDEPEND</c> except where this will create circular dependency chains.
</p>

</body>
</section>

<section>
<title>Implicit System Dependency</title>
<body>

<p>
All packages have an implicit compile-time and runtime dependency upon the
entire <c>system</c> target. It is therefore not necessary, nor advisable, to
specify dependencies upon <c>gcc</c>, <c>libc</c> and so on, except where specific
versions or packages (for example, <c>glibc</c> over <c>uclibc</c>) are required.
</p>

<p>
However, packages which are included in the <c>system</c> target, or are
dependencies of <c>system</c> target packages, should generally include a complete
dependency list (excluding bootstrap packages). This makes <c>emerge -e system</c>
possible when installing from a stage 1 or stage 2 tarball.
</p>

</body>
</section>

<section>
<title>Basic Dependency Syntax</title>
<body>

<p>
A basic <c>DEPEND</c> specification might look like the following:
</p>

<codesample lang="ebuild">
DEPEND="dev-lang/ruby
    dev-ruby/ruby-gtk2
    dev-ruby/mysql-ruby"
</codesample>

<p>
Each atom is the full category and name of a package. Atoms are separated by
arbitrary whitespace -- convention is to specify one atom per line for
readability purposes. When specifying names, the category part should be treated
as mandatory.
</p>

</body>
</section>

<section>
<title>Version Dependencies</title>
<body>

<p>
Sometimes a particular version of a package is needed. Where this is known, it
should be specified. A simple example:
</p>

<codesample lang="ebuild">
DEPEND=">=dev-libs/openssl-0.9.7d"
</codesample>

<p>
This states that at least version 0.9.7d of <c>openssl</c> is required.
</p>

<subsection>
<title>Version Specifiers</title>
<body>

<p>
Available version specifiers are:
</p>

<p>
<table>
  <tr>
    <th>Specifier</th>
    <th>Meaning</th>
  </tr>
  <tr>
    <ti><c>>=app-misc/foo-1.23</c></ti>
    <ti>Version 1.23 or later is required.</ti>
  </tr>
  <tr>
    <ti><c>>app-misc/foo-1.23</c></ti>
    <ti>A version strictly later than 1.23 is required.</ti>
  </tr>
  <tr>
    <ti><c>~app-misc/foo-1.23</c></ti>
    <ti>Version 1.23 (or any <c>1.23-r*</c>) is required.</ti>
  </tr>
  <tr>
    <ti><c>=app-misc/foo-1.23</c></ti>
    <ti>
      Exactly version 1.23 is required. If at all possible,
      use the <c>~</c> form to simplify revision bumps.
    </ti>
  </tr>
  <tr>
    <ti><c>&lt;=app-misc/foo-1.23</c></ti>
    <ti>Version 1.23 or older is required.</ti>
  </tr>
  <tr>
    <ti><c>&lt;app-misc/foo-1.23</c></ti>
    <ti>A version strictly before 1.23 is required.</ti>
  </tr>
</table>
</p>

</body>
</subsection>

<subsection>
<title>Ranged Dependencies</title>
<body>

<p>
To specify "version 2.x (not 1.x or 3.x)" of a package, it is necessary to use
the asterix postfix. This is most commonly seen in situations like:
</p>

<codesample lang="ebuild">
DEPEND="gtk2? ( >=x11-libs/gtk+-2.4 )
    !gtk2? ( =x11-libs/gtk+-1.2* )"
</codesample>

<p>
Note that the equals sign is mandatory, and that there is no dot before the
asterisk.
</p>

</body>
</subsection>

<subsection>
<title>Blockers</title>
<body>

<p>
Sometimes two packages cannot be installed in parallel. This is handled by
blockers. A blocker is specified as follows:
</p>

<codesample lang="ebuild">
RDEPEND="!app-misc/foo"
</codesample>

<p>
Note that blockers are usually <e>runtime</e> rather than buildtime.
</p>

<p>
Specific versions can also be blocked:
</p>

<codesample lang="ebuild">
RDEPEND="!&lt;app-misc/foo-1.3"
</codesample>

<p>
Blockers can be optional based upon USE flags as per normal dependencies.
</p>

</body>
</subsection>

</body>
</section>

<section>
<title>SLOT Dependencies</title>
<body>

<p>
It is not currently possible to depend upon a package in a particular <c>SLOT</c>.
This is a shame.
</p>

</body>
</section>

<section>
<title>USE-Conditional Dependencies</title>
<body>

<p>
To depend upon a certain package if and only if a given <c>USE</c> flag is set:
</p>

<codesample language="ebuild">
DEPEND="perl? ( dev-lang/perl )
    ruby? ( &gt;=dev-lang/ruby-1.8 )
    python? ( dev-lang/python )"
</codesample>

<p>
It is also possible to depend upon a certain package if a given <c>USE</c> flag is
<e>not</e> set:
</p>

<codesample language="ebuild">
RDEPEND="!crypt? ( net-misc/netkit-rsh )"
</codesample>

<p>
This should <b>not</b> be used for disabling a certain <c>USE</c> flag on a given
architecture. In order to do this, the architecture should add the <c>USE</c>
flag to their <c>use.mask</c> file in the <c>profiles/default-linux/arch</c>
directory of the Portage tree.
</p>

<p>
This can be nested:
</p>

<codesample language="ebuild">
DEPEND="gtk? (
      gtk2? ( &gt;=x11-libs/gtk+-2.4 )
      !gtk2? ( =x11-libs/gtk+-1.2* ) )
    !gtk? ( sys-libs/ncurses )"
</codesample>

</body>
</section>

<section>
<title>Virtual Dependencies</title>
<body>

<p>
To depend upon a virtual package, use <c>virtual/whatever</c> as the atom.
</p>

<p>
Currently, you must not use any kind of version specification with virtuals --
see `GLEP 37`_ for details and a proposed solution.
</p>

</body>
</section>

<section>
<title>
Any of Many Dependencies
</title>
<body>

<p>
To depend on either <c>foo</c> or <c>bar</c>:
</p>

<codesample lang="ebuild">
DEPEND="|| ( app-misc/foo app-misc/bar )"
</codesample>

<p>
To depend on either <c>foo</c> or <c>bar</c> if the <c>baz</c> <c>USE</c> flag is set:
</p>

<codesample lang="ebuild">
DEPEND="baz? ( || ( app-misc/foo app-misc/bar ) )"
</codesample>

<subsection>
<title>Any of Many Versus USE</title>
<body>

<p>
Say <c>fnord</c> can be built against either <c>foo</c> or <c>bar</c>. Then a USE flag is
not necessary if and only if all of the following hold:
</p>

<ul>
  <li>
    <c>fnord</c> is merged on a system which has <c>foo</c> and not <c>bar</c> installed.
    <c>foo</c> is then unmerged, and <c>bar</c> is installed. <c>fnord</c> must continue to
    work correctly.
  </li>
  <li>
    A binary package of <c>fnord</c> made on a system with <c>foo</c> and not <c>bar</c>
    can be taken and installed on a system with <c>bar</c> and not <c>foo</c>.
  </li>
</ul>

</body>
</subsection>

</body>
</section>

<section>
<title>Built with USE Dependencies</title>
<body>

<p>
Currently it is impossible to depend upon "<c>foo</c> built with the <c>bar</c>
<c>USE</c> flag enabled". This is a nuisance.</p>

</body>
</section>

<section>
<title>Legacy Inverse USE-Conditional Dependency Syntax</title>
<body>

<p>
When looking through old ebuild versions or the occasional user-submitted
ebuild, you may see a <c>*DEPEND</c> atom in the form:
</p>

<codesample lang="ebuild">
DEPEND="use-flag? ( app-misc/foo ) : ( app-misc/bar )"
</codesample>

<p>
<b>This syntax is no longer permitted</b>. It is exactly equivalent to the
following, which should be used instead:
</p>

<codesample lang="ebuild">
DEPEND="use-flag?  ( app-misc/foo )
    !use-flag? ( app-misc/bar )"
</codesample>

<p>
It is useful to recognise the legacy syntax and to know that it is no longer
valid.
</p>

</body>
</section>

</body>
</chapter>
</guide>