I've recently had lots of trouble getting my system to update cleanly. With --ignore-built-slot-operator-deps=yes everything worked fine, without both boost and parts of Qt got tangled into a mess of conflicting up- and downgrade suggestions.
After a lot of try-and-error I found the reason. I had a package installed where
* the installed version had been removed from the tree
* all other (newer) versions were locally package.masked
* and a rebuild was due
It would be nice if such a situation were expressed more clearly in the output.
Now I only found it because this was one of the packages trying to trigger a Qt downgrade, and I checked them all in turn...
[Interestingly in both cases with and without --ignore-built-slot-operator-deps=yes autounmask did not suggest anything about the package. Only when I tried to rebuild it manually by listing it on the command line...]
It shouldn't be too difficult to identify and highlight these packages in the slot conflict output. That will be a vast improvement over the current situation.
I've posted this patch for review:
This is in the master branch:
We could extend this to include information about other issues found in the depgraph _slot_operator_trigger_reinstalls and _slot_operator_update_probe methods. For example:
* _slot_operator_trigger_reinstalls will not call _slot_operator_update_probe if the package depth is greater than the current --deep setting
* _slot_operator_update_probe will not trigger a rebuild if it can't find an available package that satisfies the check_reverse_dependencies function
*** Bug 607244 has been marked as a duplicate of this bug. ***
Fixed in portage-2.3.5.