When an unresolved package dependency is found, portage will "backtrack" to find out if anything the user asked for doesn't have the dependency problem, and can therefore be merged without issue. It does not do this for USE dependencies. This issue manifests itself in two ways that I've seen so far:
1. If any USE flag dependency issues were found during dependency resolution, portage will immediately give up.
2. If some other dependency issue was already encountered (such as a package dependency issue), it will be printed and no message about the USE flag dependency issue be printed.
The specific place I'm encountering this is with packages which depend on udev[extras]. I didn't have the extras USE flag enabled, so I encountered these issues.
*** This bug has been marked as a duplicate of bug 258371 ***
This is not a duplicate of that bug. I am not asking that the USE dependency be automatically resolved, I am asking that portage try to do any OTHER resolution it can that does NOT have that same USE dependency.
(In reply to comment #0)
> The specific place I'm encountering this is with packages which depend on
> udev[extras]. I didn't have the extras USE flag enabled, so I encountered these
Was there some other possible solution besides enabling USE=extras? If not, then backtracking would have just been a waste of time. It's hard to imagine cases like this where backtracking would really make sense.
There were other things to be merged which did not depend on udev[extras].
So, for every package which pulled in udev[extras], there was some version of the same package that didn't pull in udev[extras]? If that was true, then backracking could have 'helped', but it wouldn't necessarily have produced an optimal solution (usually it would result in missed updates).
Say we are merging the following three packages: a, b, and c. b depends on udev[extras]. a and c do not. I want portage to be able to merge a and c.
Okay, so what you're saying is that you want it to prune off unsolvable parts of the dependency graph and just work on the parts that are solvable without any configuration changes. That's feasible, and "suggested" dependencies (bug #327701) can also come into play here when we implement them. Pruning off unsolvable parts of the dependency graph is also useful for emerge --keep-going and --resume (like in bug #263630).
Yes, I think you understand what I'm talking about now. However, portage seems to already do what I'm asking for package keyword dependencies. If portage finds one (or even multiple) of these unsatisfied dependencies, it will give you the option to install the non-conflicting things and will also print the error messages, "All packages to satisfy this dependency are masked", etc at the bottom.
*** Bug 389203 has been marked as a duplicate of this bug. ***
*** Bug 472298 has been marked as a duplicate of this bug. ***