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: https://archives.gentoo.org/gentoo-portage-dev/message/553e19a6126d6989453d9ac359650809 https://github.com/gentoo/portage/pull/77
This is in the master branch: https://gitweb.gentoo.org/proj/portage.git/commit/?id=ddbe020d9385f8b70e4ec6f085d3afa7271949d7
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.
