Gentoo Archives: gentoo-user

From: Wols Lists <antlists@××××××××××××.uk>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] A portage nuisance
Date: Sun, 29 Oct 2017 00:10:13
Message-Id: 59F51C5B.40609@youngman.org.uk
In Reply to: Re: [gentoo-user] A portage nuisance by Andrew Savchenko
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

Replies

Subject Author
Re: [gentoo-user] A portage nuisance Michael Orlitzky <mjo@g.o>