On 12/30/20 9:35 AM, Arve Barsnes wrote:
On Wed, 30 Dec 2020 at 08:46, n952162 <[email protected]> wrote:
Well, yes, the current version, indeed requires python3_8. The version
that was installed on my system, however, to be updated, listed
python3_7 in the PYTHON_TARGETS section. That was the only difference
between the two packages in the collision. It apparently disqualified
the update with a slot conflict.
I tried walking you through the massive output from portage on one of
these conflicts last week, was it helpful? The point either way, was
that the slot conflict is not setuptools itself, but further down the
dependency chain, where some package is unable to update to python
3.8, and it's dragging its dependencies back with it.
Regards,
Arve
I spent hours studying your analysis, and then I thought it was a simple
transitive-closure problem. I wrote a script that would take an emerge
log and turn it into vectors and do a TC on those, but it didn't work.
For one thing, I got tangled up in the issue of whether the "scheduled
for merge" or the "installed" section was relevant. Then I noticed that
in most (but not all) cases, the problem centered around a single
package that had multiple, slightly different (mostly in the
PYTHON_TARGETS variable) specs. At first, I thought that there was
always just one such conflict package, all the other having a single new
depender, rather than multiple. But I think now, that was a red herring.
In your analysis, I didn't see that you made a distinction between
"scheduled for emerge" and "installed" dependers. When using all
potential dependers, I just wasn't able to following any chain to a
useful conclusion. Perhaps it's there and just requires more thought.
Anyway, my blanket --depclean kind of put a stop to that direction.
