On 12/19/20 12:35 PM, Michael wrote:
On Saturday, 19 December 2020 10:20:26 GMT n952162 wrote:
I don't think this output or any list participant has actually
identified where the problem here is. In my original posting, the only
difference causing the slot collision for jinja was that one had a
PYTHON_TARGETS of 3-7 and the other of 3-8. I asked how to force it to
the correct value, but if someone explained that to me, I didn't
understand it.
You have specified manually a number of python versions, you shouldn't have.
Are you saying that long lists like this:
*"python3_8 python3_9 (-pypy3) -python3_6 -python3_7*"
are relics from improper or obsolete invocations made be me?
If so, how can I get rid of them?
It seems you have also added permanently into your /var/lib/portage/world a
large number of dependencies and libraries due to your emerge syntax when
emerging specific packages, which again, you shouldn't have.
As a result with your own inputs in your portage configuration you are
fighting against what portage is trying to do in its calculations.
I would think the easiest solution would be to work with portage, rather than
despite portage:
1. Purge from your config files any hardcoded python targets, in order to let
portage choose which python target version it requires.
I have added or removed these definitions, either following suggestions
or attempting to provide prerequisites for packages that seem to require
them.
Absolutely, the best medicine is no medicine.
2. Clean your world file from any and all dependencies, libraries and packages
you do not want to have explicitly installed.
Yes, I receive that advice a lot. If I were to follow it aggressively,
there would only be a handful of files in my world file. Will that work?
3. If 'emerge -uaNDv @system' gives you similar errors as above, try emerging
one package at a time with '--oneshot', so it does not inadvertently end up in
your world; e.g.
emerge -1aNDv <package name>
I can't get *anything* to emerge, either alone, with near dependencies
(as in the orginal posting) or in sets.
Do not specify a package version in the above, just a name only. Let portage
install the version it calculates is appropriate and update any dependencies
needed.
I never do.
If your toolchain is completely borked, you could try the same by
using a Live-CD and a latest portage snapshot as per the guide book.
Is that much different than a re-install?
4. When you finish emerging @system you should have a sound toolchain to build
the rest of your Gentoo installation with. Run the following:
etc-update (to update your system configuration files)
emerge --depclean -v -a (to unmerge packages/versions no longer needed)
5. Follow with 'emerge -uaNDv @world'.
6. When you finish all this run:
etc-update
emerge -v -a @preserved-rebuild --keep-going
emerge --depclean -v -a
revdep-rebuild -v -- -a
/usr/bin/eclean-dist
7. Build the latest kernel, update grub's menu, reboot.
Yes, I perform these steps, basically, once I get an update emerge to work.
I update the /etc/portage/package.use files by hand, so I get a feeling
for how it works. Can it be that etc-update is a "smart system" that
does more than just that?
/Is there a fundamental goals issue here, when there's so much
incompatibility between python3_{6,7,8,9}? Do packages really need to
care? Are these versions so fundamentally different from each other,
and programmers rely on those differences? Or, is this somebody's
orderliness tic?/
Portage runs on python and it is also a dependency on a large number of other
packages and scripts. As python upstream is gradually deprecating older
versions, Gentoo has to follow through with the migration. The portage tree
is presently in a relative state of flux because of this, but it should soon
slow down again.
/What I'm wondering is if packages aren't specifying with too fine a
granularity./
If your system is borked for unknown reasons and following the above
suggestions you can't arrive at a stable state, perhaps it is time for you to
reinstall - which by the look of things it ought to take less of your time?
I was thinking I'd just re-installed this system but I guess that had
just been a painful @world update - I see that I installed it last
year. If I continue not being able to get a single emerge, I guess
that's how I'll have to go.
I'm surprised, though, that nobody could address the reduced case I
presented in the original posting:
- is the same package being re-installed with new python target
requirements, or am I interpreting it wrongly?
- is there no way to satisfy the differing python target requirements?
- are there consequences on other packages to emerging this package
that make it impossible?
