On Sat, 28 Oct 2017 22:59:26 +0100 Anthony Youngman wrote:
[...]
> All I'm asking is that as it progresses, it makes a list of those 
> packages it can resolve the dependencies for. If it then gives up with 
> the current list it's processing, eg "world", it then goes back to the 
> list it thinks it can process, and has another go with them.
> 
> Because that's exactly what I do, take the first few packages off the 
> list that look fine, and emerge them. I then re-run the original emerge, 
> rinse and repeat, but it takes absolutely ages, and worse I have to 
> babysit the emerge because I'm *expecting* it to hit a problem.
[...]
> To give you a very clear example of what I'm thinking ...
> 
> emerge -u world
> A will be emerged with options ...
> B will be emerged with options ...
> C will be emerged with options ...
> D is blocked by E
> F will be emerged with options ...
> G is blocked by H
> Giving up, too many circular dependencies
> emerge A B C F

Ah, man, this is where your mistake is. You are assuming that it
 is possible to get a correct dependency subgraph without building
full correct dependency graph first. This is not possible and this
is math. While the approach you described abode may work in some
practical cases, it will be busted in general case.

The key moment here is that graph's root node may be changed during
dependency recalculation based on _how_ conflict is solved, the
same as all other nodes may be reordered. And dependencies which
appear to be valid before conflict is resolved may became invalid
after, consider the following dep tree:

  A
 / \
B   C
    |
 !{D,E}

- B and C depends on A;
- D conflicts with E and both depend on C;

You assume that !{D,E} conflict can be skipped and A, B, C canbe
emerged. But let's assume that you selected D later, but D depends
on F and F conflicts with A[some_flag]. So you'll have to choose
some alternative to A or change its USE flags, this may require to
rebuild the whole dependency tree (and build order may change as
well). In order to prevent dozens (sometimes hundreds or even
thousands) of useless rebuilds and to avoid leaving intermediate
tree in the utterly broken state emerge fails if it can't build the
dependency graph.

Maybe my example above is synthetic and not the best one, you
should understand that dependencies are very complex, may be
intricately interconnected and there is no way to tell which parts
are correct until all picture is seen.

Best regards,
Andrew Savchenko