Created attachment 724042 [details] Portage output This is a request to improve this type of dependency handling in Portage. As one can see in the attachment for the two blockers, several packages are marked for update but it changes the Python target. A blocker occrus because Portage does not attempt to rebuild/update dependant packages that are on an older version, older Python slot, than the same package pulled in. We can add 'jinja' to the emerge command and the packages will now solve all dependencies. Without resolving these automatically and without the old 'python-updater' type packages, both Python and Perl end up with endless walls of text of blocking packages that make updating a system troublesome. I also think this kind of output is very dense and mostly debug like looking and it greatly helps if the dependant package that is blocking is highlighted. So the above output would instead look like: --- dev-python/setuptools:0 dev-python/jinja-2.11.2-r1, USE="-doc -examples -test" PYTHON_TARGETS="python3_7" --- The output also mentions it seems to want setuptools pulled in but since it is already pulled in it is not an issue. Which is wierd, because it is "polluting" the debug output without requiring a manual pull to resolve the slot conflict issues. Please let me know how I can help with this, as I have been working with Python nowadays. Browsing the portage code didn't take me to the right code though, so help of where to look is very appreciated.
You weren't doing a full upgrade (either with @world or at least --complete-graph or --deep) so it makes sense not everything got pulled in. https://wiki.gentoo.org/wiki/Project:Portage/FAQ#Why_is_there_a_dependency_conflict_when_I_attempt_to_upgrade_a_single_package.3F *** This bug has been marked as a duplicate of bug 559354 ***
