python-exec-2.4.8 requires python-exec-conf which requires
python-exec 2.4.6?
I was going to wonder if you are caught in the middle of an upgrade
that's only partly reached the mirrors. Given that (as I see it,
having last done a sync a few hours ago) that there is ONLY one version
each in the tree for python-exec-2.4.8 and python-exec-conf-2.4.6.
However, looking at the ebuilds:
python-exe requires python-exec-conf (no version specified) python-exec-conf-2.4.6 requires "!<dev-lang/python-exec-2.4.6-r4" which should allow 2.4.8.
I have both python 3.9.9-r1 and 3.10.0_p1-r1 installed (plus
2.7.18_p13) so there doesn't seem to be any conflict there. What does "equery d python-exec" tell you?
Still not sure what command one uses to determine what package is
preventing some other package from being upgraded...
On Wed, 12 Jan 2022 at 01:44, Grant Edwards <grant.b.edwards@gmail.com> wrote:
Still not sure what command one uses to determine what package is
preventing some other package from being upgraded...
It should all be in the emerge output, although it's quite hard to read.
If you want help interpreting it you could post the complete conflict
output, but what you've posted in your initial message is just the bit
that says that python-exec-2.4.8 requires python-exec-conf-2.4.6.
That's not a conflict, that's just one of the packages having one
dependency. To have a conflict, a different package would need to
require a different version.
Most of the times this particular kind of conflict is with an older
package that requires older PYTHON_TARGETS than can be provided, and I
expect something that got depcleaned with ipkg-utils, or ipkg-utils
directly, required python-exec or python-exec-conf with PYTHON_TARGETS="python3_7". Note that dev-lang/python itself is not
the source of any of these problems, I still have python 2.7 and 3.10 installed (along with 3.9 which is the default version on this machine
now).
Then it must have been ipkg-utils itself that required the older
python_exec, but there was no ebuild present for it.
On Wed, 12 Jan 2022 14:53:06 -0000 (UTC), Grant Edwards wrote:
Then it must have been ipkg-utils itself that required the older
python_exec, but there was no ebuild present for it.
If it was installed through portage, there would have been an ebuild
for it, in /var/db/pkg.
That's what portage was referencing when if made the dependency
calculations.
If it was installed through portage, there would have been an ebuild
for it, in /var/db/pkg.
Yes, correct past tense. There was at some point in the past when
ipkg-utils was installed.
That's what portage was referencing when if made the dependency calculations.
There was no ipkg ebuild. There had been in the past, but it was
removed during an emerge --sync a while back. Last rites on 1 Aug
2020, removal 30 days later: https://www.mail-archive.com/gentoo-dev@lists.gentoo.org/msg90135.html
My conclusion was that dependency info for currently installed
packages is also stored somewhere else, since emerge still knew that python-2.7 was required for ipkg-utils.
On Wed, 12 Jan 2022 16:25:29 -0000 (UTC), Grant Edwards wrote:
If it was installed through portage, there would have been an ebuild
for it, in /var/db/pkg.
Yes, correct past tense. There was at some point in the past when
ipkg-utils was installed.
That's what portage was referencing when if made the dependency
calculations.
There was no ipkg ebuild. [...]
The ebuild would still have been on /var/db/pkg as long as it was
installed.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 286 |
Nodes: | 16 (2 / 14) |
Uptime: | 91:00:57 |
Calls: | 6,496 |
Calls today: | 7 |
Files: | 12,100 |
Messages: | 5,277,688 |