1 |
>>>>> On Sun, 19 Jun 2011, Ciaran McCreesh wrote: |
2 |
|
3 |
> On Sun, 19 Jun 2011 23:21:02 +0200 Micha³ Górny <mgorny@g.o> wrote: |
4 |
>> I added a note about the possible circular RDEPEND issue. |
5 |
|
6 |
> I still don't think we should be specifying "RDEPEND is PDEPEND if |
7 |
> the package manager feels like it". That's something for the package |
8 |
> mangler to provide as a horrible --ignore-dependencies-to-break-cycles |
9 |
> option. |
10 |
|
11 |
It's _not_ saying that RDEPEND is like PDEPEND in some cases. The |
12 |
assertion from your previous message in this thread will always hold: |
13 |
|
14 |
| The intention with the "usable" stuff is this that purely RDEPEND |
15 |
| cycles are resolvable, but any such cycles must be resolved before |
16 |
| any package which has a DEPEND upon anything in the cycle is |
17 |
| resolved. So if you've got this: |
18 |
| |
19 |
| first <-- rdepend --- second <-- depend --- third |
20 |
| --- rdepend --> |
21 |
| |
22 |
| Then (first, second, third) and (second, first, third) are the only |
23 |
| legal orderings. But if either RDEPEND became a DEPEND (and if we're |
24 |
| not dealing with binary packages) then there would be no legal |
25 |
| ordering. |
26 |
|
27 |
This is long-standing Portage behaviour (introduced in 2006 with the |
28 |
patches attached to bug 147766, I believe). |
29 |
|
30 |
The footnote would only clarify that in your example neither "first" |
31 |
nor "second" can rely on their rdepend being available in pkg_*inst. |
32 |
|
33 |
Ulrich |