1 |
>>>>> On Wed, 24 Jan 2018, Martin Vaeth wrote: |
2 |
|
3 |
> Ulrich Mueller <ulm@g.o> wrote: |
4 |
>> "Runtime dependencies (RDEPEND). These must be installed and usable |
5 |
>> before the results of an ebuild merging are treated as usable." |
6 |
>> https://projects.gentoo.org/pms/6/pms.html#x1-770008.1 |
7 |
>> |
8 |
>> IMHO this implies that the dependencies at merge time are the |
9 |
>> relevant ones |
10 |
|
11 |
> IMHO this specifies what is relevant when an emerge merging happens. |
12 |
> Nothing more, nothing less. |
13 |
|
14 |
Exactly. RDEPEND is to be evaluated at the time before the package is |
15 |
merged. For PDEPEND it is even clearer: "These must be installed at |
16 |
some point before the package manager finishes the batch of installs." |
17 |
|
18 |
> _If_ one would be willing to interpret it to have a meaning also |
19 |
> _after_ the emerge, then of course the RDEPEND in PMS can refer to |
20 |
> the only value which is specified in PMS, i.e. that stored in the |
21 |
> ebuild |
22 |
|
23 |
... at the time when the package was merged. You cannot rely on |
24 |
anything else, because the ebuild may be gone in the meantime. |
25 |
|
26 |
> (and not in any database which is explicitly not specified by PMS). |
27 |
> In other words: _If_ one puts any unsaid interpretation into that |
28 |
> sentence, then this can only be dynamic deps. |
29 |
|
30 |
No. The only thing that PMS doesn't specify is the special format of |
31 |
the VDB. However, the spec says that variables must keep their values |
32 |
between phase functions, which includes pkg_prerm() and pkg_postrm(). |
33 |
By this, *some* sort of storage mechanism must exist. |
34 |
|
35 |
Ulrich |