On Wednesday, 30 December 2020 07:22:34 GMT n952162 wrote:
> On 12/30/20 1:05 AM, Michael wrote:
> > On Tuesday, 29 December 2020 22:55:03 GMT Neil Bothwick wrote:
> >> On Tue, 29 Dec 2020 23:16:11 +0100, n952162 wrote:
> >>>> So, I tried to do an emerge on @system.  I got another slot conflict!
> >>>> This time for mako, which I'd seen go by sometimes as a "package of
> >>>> interest".  It's only transgression: PYTHON_TARGET containing
> >>>> python3_7.
> >>> 
> >>> Note that both the "scheduled for merge" depender and the "installed"
> >>> depender both required the same version of mako, 1.1.1-r1.  The only
> >>> difference is the fact that one requirements specification has
> >>> python3-7, the other python3-8.  The same pkg, the same binaries.
> >>> Something is wrong here.  Why is it not good enough to specify python3?
> >> 
> >> PYTHON_TARGET determines for which version(s) of Python a package
> >> installs its modules. The modules may be identical, but 3.7 and 3.8 have
> >> different search paths, e.g. /usr/lib/python3.7/site-packages vs.
> >> /usr/lib/python3.8/site-packages.
> >> 
> >> It is possible you have some old python_targets settings in package.use,
> >> that's where I would check first.
> > 
> > As discussed recently, removing any manually configured python targets and
> > letting portage work its magic, rather than fighting against it, is
> > usually a sound way to get out of such a muddle.
> 
> I don't understand what manually configured python targets are. There
> are, in general, no python specifiers on my system in
> /etc/portage/package.use or make.conf.  Do you mean somewhere else?

I mean:

'/etc/portage/package.use' and any files if it is a directory, or under any 
subdirectories therein.

'/etc/portage/make.conf'

Any files referred to in /etc/portage/env/ or /etc/portage/package.env if you 
have configured any package specific emerge parameters there yourself.

Any python related entries in /var/lib/portage/world.

Run 'eselect python list' as well as 'cleanup' & 'update' to make sure there 
are no old version symlinks hanging on.

If there is some deep dependency indicated by the output of emerge still 
asking for an old(er) python version, which portage will not resolve itself, 
then quickpkg it, uninstall it and re-run emerge.

The above ought to get a stable portage able to update itself into a clean 
state.