1 |
On 28/10/17 23:45, Andrew Savchenko wrote: |
2 |
>> emerge -u world |
3 |
>> > A will be emerged with options ... |
4 |
>> > B will be emerged with options ... |
5 |
>> > C will be emerged with options ... |
6 |
>> > D is blocked by E |
7 |
>> > F will be emerged with options ... |
8 |
>> > G is blocked by H |
9 |
>> > Giving up, too many circular dependencies |
10 |
>> > emerge A B C F |
11 |
> Ah, man, this is where your mistake is. You are assuming that it |
12 |
> is possible to get a correct dependency subgraph without building |
13 |
> full correct dependency graph first. This is not possible and this |
14 |
> is math. While the approach you described abode may work in some |
15 |
> practical cases, it will be busted in general case. |
16 |
> |
17 |
> The key moment here is that graph's root node may be changed during |
18 |
> dependency recalculation based on _how_ conflict is solved, the |
19 |
> same as all other nodes may be reordered. And dependencies which |
20 |
> appear to be valid before conflict is resolved may became invalid |
21 |
> after, consider the following dep tree: |
22 |
> |
23 |
> A |
24 |
> / \ |
25 |
> B C |
26 |
> | |
27 |
> !{D,E} |
28 |
> |
29 |
> - B and C depends on A; |
30 |
> - D conflicts with E and both depend on C; |
31 |
> |
32 |
> You assume that !{D,E} conflict can be skipped and A, B, C canbe |
33 |
> emerged. But let's assume that you selected D later, but D depends |
34 |
> on F and F conflicts with A[some_flag]. So you'll have to choose |
35 |
> some alternative to A or change its USE flags, this may require to |
36 |
> rebuild the whole dependency tree (and build order may change as |
37 |
> well). In order to prevent dozens (sometimes hundreds or even |
38 |
> thousands) of useless rebuilds and to avoid leaving intermediate |
39 |
> tree in the utterly broken state emerge fails if it can't build the |
40 |
> dependency graph. |
41 |
|
42 |
EXCEPT. |
43 |
|
44 |
My "emerge A B C F" will presumably then fail with those conflicts, and |
45 |
it will loop again and just do an "emerge A". |
46 |
|
47 |
I'm not saying "prune the graph first time, then just emerge |
48 |
everything". I'm saying "prune the graph, and try again with the reduced |
49 |
set". |
50 |
|
51 |
Thing is, I have always found that deleting blockers "emerge -C1", and |
52 |
emerging everything that I can get to emerge, is almost guaranteed to |
53 |
end up with a system where everything eventually emerges. |
54 |
|
55 |
The problem I have is that, if I delay updating (or something like kde |
56 |
with its gazillions of packages is upgraded), I end up with maybe 300 |
57 |
packages to be emerged. Trying to sort that mess out is a nightmare |
58 |
especially when emerge starts blowing up with circular dependencies and |
59 |
stuff, and old packages blocking new ones - "A version 2 is blocked by A |
60 |
version 1" etc etc. And all too often deleting the current version A |
61 |
(and the other packages - slated for replacement - that depend on A) |
62 |
fixes the problem. |
63 |
|
64 |
I think we're having a misunderstanding here. If emerge does what I'm |
65 |
asking for, and leaves the system in a broken state (as you seem to |
66 |
think it will), then that's a serious bug in emerge. You seem to think |
67 |
I'm asking emerge to prune the dependency tree - I'm not. I'm asking for |
68 |
it to prune the package list - if it can't sort out dependencies, drop |
69 |
that package from the package list and then, when it's got a list of |
70 |
packages that it thinks will work, go back to the start and try to |
71 |
emerge just those (calculating a new dependency tree). |
72 |
|
73 |
In other words, I'm asking emerge to automate what I do - look at the |
74 |
output, find a subset of packages that I think will work, and then ask |
75 |
it to try again with just those packages. I would be very surprised if |
76 |
it iterated repeatedly down to the null set. |
77 |
|
78 |
As for doing useless rebuilds, isn't that MY call, not yours? What is |
79 |
most valuable - my time, or my computer's time? As it stands, I have to |
80 |
babysit an emerge - calculating the full graph bombs, so I have to try |
81 |
to emerge a small subset, which might bomb, and when that works I try |
82 |
again with the full set that bombs, so I have to iterate again, ad |
83 |
nauseam ... I like to work on the principle "if the computer can |
84 |
automate what I do, then it should ..." |
85 |
|
86 |
What would you recommend as the best way (for somebody who's knowledge |
87 |
of gentoo is patchy) of dealing with the situation when an emerge blows |
88 |
up with loads of circular dependencies finishing with the message "too |
89 |
many errors, giving up"? As opposed to my way of "emerge what I can, |
90 |
then see what more emerges", which I have always found eventually fixes |
91 |
everything. |
92 |
|
93 |
Cheers, |
94 |
Wol |