1 |
On Wednesday, 30 December 2020 07:22:34 GMT n952162 wrote: |
2 |
> On 12/30/20 1:05 AM, Michael wrote: |
3 |
> > On Tuesday, 29 December 2020 22:55:03 GMT Neil Bothwick wrote: |
4 |
> >> On Tue, 29 Dec 2020 23:16:11 +0100, n952162 wrote: |
5 |
> >>>> So, I tried to do an emerge on @system. I got another slot conflict! |
6 |
> >>>> This time for mako, which I'd seen go by sometimes as a "package of |
7 |
> >>>> interest". It's only transgression: PYTHON_TARGET containing |
8 |
> >>>> python3_7. |
9 |
> >>> |
10 |
> >>> Note that both the "scheduled for merge" depender and the "installed" |
11 |
> >>> depender both required the same version of mako, 1.1.1-r1. The only |
12 |
> >>> difference is the fact that one requirements specification has |
13 |
> >>> python3-7, the other python3-8. The same pkg, the same binaries. |
14 |
> >>> Something is wrong here. Why is it not good enough to specify python3? |
15 |
> >> |
16 |
> >> PYTHON_TARGET determines for which version(s) of Python a package |
17 |
> >> installs its modules. The modules may be identical, but 3.7 and 3.8 have |
18 |
> >> different search paths, e.g. /usr/lib/python3.7/site-packages vs. |
19 |
> >> /usr/lib/python3.8/site-packages. |
20 |
> >> |
21 |
> >> It is possible you have some old python_targets settings in package.use, |
22 |
> >> that's where I would check first. |
23 |
> > |
24 |
> > As discussed recently, removing any manually configured python targets and |
25 |
> > letting portage work its magic, rather than fighting against it, is |
26 |
> > usually a sound way to get out of such a muddle. |
27 |
> |
28 |
> I don't understand what manually configured python targets are. There |
29 |
> are, in general, no python specifiers on my system in |
30 |
> /etc/portage/package.use or make.conf. Do you mean somewhere else? |
31 |
|
32 |
I mean: |
33 |
|
34 |
'/etc/portage/package.use' and any files if it is a directory, or under any |
35 |
subdirectories therein. |
36 |
|
37 |
'/etc/portage/make.conf' |
38 |
|
39 |
Any files referred to in /etc/portage/env/ or /etc/portage/package.env if you |
40 |
have configured any package specific emerge parameters there yourself. |
41 |
|
42 |
Any python related entries in /var/lib/portage/world. |
43 |
|
44 |
Run 'eselect python list' as well as 'cleanup' & 'update' to make sure there |
45 |
are no old version symlinks hanging on. |
46 |
|
47 |
If there is some deep dependency indicated by the output of emerge still |
48 |
asking for an old(er) python version, which portage will not resolve itself, |
49 |
then quickpkg it, uninstall it and re-run emerge. |
50 |
|
51 |
The above ought to get a stable portage able to update itself into a clean |
52 |
state. |