Re: [gentoo-user] override PYTHON_TARGETS to avoid a slot collision

[n952162 <n952162@web.de>]

[-- Attachment #1: Type: text/plain, Size: 5092 bytes --]

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?




[-- Attachment #2: Type: text/html, Size: 7610 bytes --]