Re: [gentoo-user] A portage nuisance

[Wols Lists <antlists@youngman.org.uk>]

On 28/10/17 23:45, Andrew Savchenko wrote:
>> 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.

EXCEPT.

My "emerge A B C F" will presumably then fail with those conflicts, and
it will loop again and just do an "emerge A".

I'm not saying "prune the graph first time, then just emerge
everything". I'm saying "prune the graph, and try again with the reduced
set".

Thing is, I have always found that deleting blockers "emerge -C1", and
emerging everything that I can get to emerge, is almost guaranteed to
end up with a system where everything eventually emerges.

The problem I have is that, if I delay updating (or something like kde
with its gazillions of packages is upgraded), I end up with maybe 300
packages to be emerged. Trying to sort that mess out is a nightmare
especially when emerge starts blowing up with circular dependencies and
stuff, and old packages blocking new ones - "A version 2 is blocked by A
version 1" etc etc. And all too often deleting the current version A
(and the other packages - slated for replacement - that depend on A)
fixes the problem.

I think we're having a misunderstanding here. If emerge does what I'm
asking for, and leaves the system in a broken state (as you seem to
think it will), then that's a serious bug in emerge. You seem to think
I'm asking emerge to prune the dependency tree - I'm not. I'm asking for
it to prune the package list - if it can't sort out dependencies, drop
that package from the package list and then, when it's got a list of
packages that it thinks will work, go back to the start and try to
emerge just those (calculating a new dependency tree).

In other words, I'm asking emerge to automate what I do - look at the
output, find a subset of packages that I think will work, and then ask
it to try again with just those packages. I would be very surprised if
it iterated repeatedly down to the null set.

As for doing useless rebuilds, isn't that MY call, not yours? What is
most valuable - my time, or my computer's time? As it stands, I have to
babysit an emerge - calculating the full graph bombs, so I have to try
to emerge a small subset, which might bomb, and when that works I try
again with the full set that bombs, so I have to iterate again, ad
nauseam ... I like to work on the principle "if the computer can
automate what I do, then it should ..."

What would you recommend as the best way (for somebody who's knowledge
of gentoo is patchy) of dealing with the situation when an emerge blows
up with loads of circular dependencies finishing with the message "too
many errors, giving up"? As opposed to my way of "emerge what I can,
then see what more emerges", which I have always found eventually fixes
everything.

Cheers,
Wol