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 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?