| 1 |
Michael Orlitzky <mjo@g.o> writes: |
| 2 |
|
| 3 |
> On 12/08/2017 09:53 AM, Melleus wrote: |
| 4 |
>> I had moved to v 17.0 profile mostly painless, though it was a time |
| 5 |
>> consuming event. But I got one point anyway. Python in my system was |
| 6 |
>> updated from 3.4 to 3.5 and after 3.4 was removed with depclean, the |
| 7 |
>> option for v 3.4 in eselect python remains. It looks a bit weird to me |
| 8 |
>> when I can choose with eselect the version of python that is not |
| 9 |
>> currently present in the system. Is this intended behavior? |
| 10 |
> |
| 11 |
> Guessing: no. (What happens if you select it?) |
| 12 |
It selects, but when attempting to run Python it falls back to v3.5 |
| 13 |
|
| 14 |
> There might be some python-3.4 stuff left on your system that tricks |
| 15 |
> eselect into thinking that python-3.4 is installed. For example, in |
| 16 |
> eselect-php we do, |
| 17 |
> |
| 18 |
> find_targets() { |
| 19 |
> cd "@LIBDIR@" && echo php*.* |
| 20 |
> } |
| 21 |
> |
| 22 |
> and that is easily fooled by creating any file in /usr/lib/php-x.y. |
| 23 |
I could not find any remnants of Python v3.4 in my system. Though I'm |
| 24 |
more academician than a IT guru. I moved to Gentoo as the last |
| 25 |
mainstream distribution free from systemd. I like its flexibility, but |
| 26 |
the maintenance of a binary distribution would be much less burden for |
| 27 |
me and for my quite old hardware. |
| 28 |
|
| 29 |
> You might have to dig through eselect-python to see how it works, or ask |
| 30 |
> somebody who knows. |
| 31 |
After some digging in the files I commented out v3.4 line in |
| 32 |
/etc/python-exec/python-exec.conf by hand and eselect then begins to |
| 33 |
work as I expect. The question is that I think that I should not edit |
| 34 |
that file by hand. So is it a bug or might I done something wrong? |
| 35 |
|
| 36 |
Thank you for pointing me in right direction. |
| 37 |
|
| 38 |
Regards, |
| 39 |
Anatoly. |
Archives