Summary: | =dev-python/qtawesome-1.0.2: pkg_resources.ContextualVersionConflict: (chardet 4.0.0 (/usr/lib/python3.8/site-packages), Requirement.parse('chardet<4,>=3.0.2') , {'requests'}) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Bernd <waebbl-gentoo> |
Component: | Current packages | Assignee: | Andrey Grozin <grozin> |
Status: | RESOLVED OBSOLETE | ||
Severity: | minor | CC: | andrewammerlaan, jstein, proxy-maint, python |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
qtawesome-1.0.2:20201218-093328.log
emerge-info-qtawesome-1.0.2.txt |
Description
Bernd
2020-12-18 11:03:08 UTC
Created attachment 678721 [details]
qtawesome-1.0.2:20201218-093328.log
build log
Created attachment 678724 [details]
emerge-info-qtawesome-1.0.2.txt
output of emerge --info qtawesome
Done after manually updating requests and qtawesome.
The bug is in dev-python/requests not in dev-python/qtawesome, as can be seen here: pkg_resources.DistributionNotFound: The 'chardet<4,>=3.0.2' distribution was not found and is required by requests It's probably not in requests. As I wrote in my initial comment, the qtawesome package came between chardet and requests updates and there was a change from <chardet-4 to <chardet-5 in the old and new requests package. Requests has correct dependencies, but qtawesome came inbetween the updates of chardet and requests, which is technically correct, as qtawesome doesn't depend on requests directly. Due to it's indirect dependency on requests it should have been updated after the requests update. The problem is likely downwards in the dependency chain, qtawesome depends on requests as follows: qtawesome QtPy PyQt5 qtxml qtnetwork libproxy spidermonkey rust llvm recommmark sphinx requests I suspect that somewhere in the chain a dependency is set as PDEPEND, which tells emerge to allow the dependecny to be emerged after the package has been emerged. Your dependency chain is correct. But if you look at it on the ebuild level it is just qtawesome -> distutils-r1 -> sphinx -> requests, so I doubt that it's a problem with someone down the chain has set a PDEPEND value. Having a rather complex setup with a huge amount of installed packages, a @world update doesn't give a single linear dependency chain. In the resulting dependency graph you will likely get several quasi-linear chains which could, at least partially, be executed in parallel (but I don't do parallel emerge execution). There might be packages for which there's no simple decision about where in the chain it needs to be installed. It might be possible that this issue cannot be resolved at all, as with several emerge runs of said complexity you can get different installation orders. I see this from time to time, that single packages have a different order on multiple emerge -p runs. The package version is no longer in tree. Closing this as obsolete. |