Trying to resolve today's Gentoo updates dependency glitch, I've uninstalled both pyparsing and packaging. This turned out to be deadly for both. Now as packaging depends on pyparsing, I've tried to install pyparsing first. This unfortunately turned out to be impossible as such: python3.9 setup.py build -j 1 Traceback (most recent call last): File "/var/tmp/portage/dev-python/pyparsing-2.4.7-r1/work/pyparsing-pyparsing_2.4.7/setup.py", line 18, in <module> setup(# Distribution meta-data File "/usr/lib/python3.9/site-packages/setuptools/__init__.py", line 153, in setup return distutils.core.setup(**attrs) File "/usr/lib/python3.9/distutils/core.py", line 108, in setup _setup_distribution = dist = klass(attrs) File "/usr/lib/python3.9/site-packages/setuptools/dist.py", line 455, in __init__ _Distribution.__init__(self, { File "/usr/lib/python3.9/distutils/dist.py", line 292, in __init__ self.finalize_options() File "/usr/lib/python3.9/site-packages/setuptools/dist.py", line 806, in finalize_options for ep in sorted(eps, key=by_order): File "/usr/lib/python3.9/site-packages/setuptools/dist.py", line 805, in <lambda> eps = map(lambda e: e.load(), pkg_resources.iter_entry_points(group)) File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 2449, in load self.require(*args, **kwargs) File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 2472, in require items = working_set.resolve(reqs, env, installer, extras=self.extras) File "/usr/lib/python3.9/site-packages/pkg_resources/__init__.py", line 772, in resolve raise DistributionNotFound(req, requirers) pkg_resources.DistributionNotFound: The 'packaging>=20.0' distribution was not found and is required by the application Reproducible: Always Steps to Reproduce: 1. uninstall pyparsing and packaging 2. try to install them again (as they are needed by many other python stuff) 3. Actual Results: Entire update process of the system critically blocked as these are vital dependencies. Installation failure due to circular dependency. Expected Results: both packages installed
Created attachment 760249 [details] emerge --info
Isn't the problem that you removed them? We've had issues like this before (see the setuptools_scm news item) but by removing things, a different (worse) situation has arisen. You should never need to unmerge packages unless a news item tells you to.
Is there any better option than system reinstall available?
(In reply to Sam James from comment #2) > Isn't the problem that you removed them? We've had issues like this before > (see the setuptools_scm news item) but by removing things, a different > (worse) situation has arisen. > > You should never need to unmerge packages unless a news item tells you to. (Also, the advice in that news item should help you here: setuptools_scm is why it wants packaging. quickpkg it for a backup then unmerge setuptools_scm then go from there.) I also don't know what your dependency glitch was but unmerging stuff made it way worse.
(In reply to Sam James from comment #4) > (In reply to Sam James from comment #2) > > Isn't the problem that you removed them? We've had issues like this before > > (see the setuptools_scm news item) but by removing things, a different > > (worse) situation has arisen. > > > > You should never need to unmerge packages unless a news item tells you to. > > (Also, the advice in that news item should help you here: setuptools_scm is > why it wants packaging. quickpkg it for a backup then unmerge setuptools_scm > then go from there.) > > I also don't know what your dependency glitch was but unmerging stuff made > it way worse. But focusing on the now, trying to describe on mobile, it's not obvious from the stacktrace but certain Python packages register as handlers. Something has registered with setuptools which then ends up needing packaging. We're going to unmerge setuptools_scm as a one off then try to emerge --oneshot packaging.
Removal of setuptools_scm indeed helped. Now the system is back to its sanity. But IMO this should be reflected in the ebuilds, so it could help the system return its sanity much easier. The glitch itself was causes by dev-python/translate-toolkit and was solved by just removing it.
(In reply to Paul Osmialowski from comment #6) > Removal of setuptools_scm indeed helped. Now the system is back to its > sanity. But IMO this should be reflected in the ebuilds, so it could help > the system return its sanity much easier. > It can't be, see my explanation of the hooks. It's not a direct dependency. setuptools_scm depends on packaging which depends on pyparsing. If setuptools_scm is installed, setuptools will try to use it (this is what your first log showed). But that fails because packaging can't work. The ebuilds already reflect all necessary dependencies. > The glitch itself was causes by dev-python/translate-toolkit and was solved > by just removing it. Deselecting and depcleaning, right? :)
(In reply to Sam James from comment #7) > (In reply to Paul Osmialowski from comment #6) > > Removal of setuptools_scm indeed helped. Now the system is back to its > > sanity. But IMO this should be reflected in the ebuilds, so it could help > > the system return its sanity much easier. > > > > It can't be, see my explanation of the hooks. It's not a direct dependency. > > setuptools_scm depends on packaging which depends on pyparsing. If > setuptools_scm is installed, setuptools will try to use it (this is what > your first log showed). But that fails because packaging can't work. > > The ebuilds already reflect all necessary dependencies. > ...and if you'd tried to depclean pyparsing or packaging, emerge wouldn't have let you, because it wasn't safe to do so. > > The glitch itself was causes by dev-python/translate-toolkit and was solved > > by just removing it. > > Deselecting and depcleaning, right? :)
@Sam thanks for handling it. The situation is clear now.
(In reply to Paul Osmialowski from comment #9) > @Sam thanks for handling it. The situation is clear now. No worries and I hope your morning gets a lot better now!
