1 |
On Sat, 28 Oct 2017 22:59:26 +0100 Anthony Youngman wrote: |
2 |
[...] |
3 |
> All I'm asking is that as it progresses, it makes a list of those |
4 |
> packages it can resolve the dependencies for. If it then gives up with |
5 |
> the current list it's processing, eg "world", it then goes back to the |
6 |
> list it thinks it can process, and has another go with them. |
7 |
> |
8 |
> Because that's exactly what I do, take the first few packages off the |
9 |
> list that look fine, and emerge them. I then re-run the original emerge, |
10 |
> rinse and repeat, but it takes absolutely ages, and worse I have to |
11 |
> babysit the emerge because I'm *expecting* it to hit a problem. |
12 |
[...] |
13 |
> To give you a very clear example of what I'm thinking ... |
14 |
> |
15 |
> emerge -u world |
16 |
> A will be emerged with options ... |
17 |
> B will be emerged with options ... |
18 |
> C will be emerged with options ... |
19 |
> D is blocked by E |
20 |
> F will be emerged with options ... |
21 |
> G is blocked by H |
22 |
> Giving up, too many circular dependencies |
23 |
> emerge A B C F |
24 |
|
25 |
Ah, man, this is where your mistake is. You are assuming that it |
26 |
is possible to get a correct dependency subgraph without building |
27 |
full correct dependency graph first. This is not possible and this |
28 |
is math. While the approach you described abode may work in some |
29 |
practical cases, it will be busted in general case. |
30 |
|
31 |
The key moment here is that graph's root node may be changed during |
32 |
dependency recalculation based on _how_ conflict is solved, the |
33 |
same as all other nodes may be reordered. And dependencies which |
34 |
appear to be valid before conflict is resolved may became invalid |
35 |
after, consider the following dep tree: |
36 |
|
37 |
A |
38 |
/ \ |
39 |
B C |
40 |
| |
41 |
!{D,E} |
42 |
|
43 |
- B and C depends on A; |
44 |
- D conflicts with E and both depend on C; |
45 |
|
46 |
You assume that !{D,E} conflict can be skipped and A, B, C canbe |
47 |
emerged. But let's assume that you selected D later, but D depends |
48 |
on F and F conflicts with A[some_flag]. So you'll have to choose |
49 |
some alternative to A or change its USE flags, this may require to |
50 |
rebuild the whole dependency tree (and build order may change as |
51 |
well). In order to prevent dozens (sometimes hundreds or even |
52 |
thousands) of useless rebuilds and to avoid leaving intermediate |
53 |
tree in the utterly broken state emerge fails if it can't build the |
54 |
dependency graph. |
55 |
|
56 |
Maybe my example above is synthetic and not the best one, you |
57 |
should understand that dependencies are very complex, may be |
58 |
intricately interconnected and there is no way to tell which parts |
59 |
are correct until all picture is seen. |
60 |
|
61 |
Best regards, |
62 |
Andrew Savchenko |