0

I have faced with an issue that when I search proper version of python I every time found python 3.7:

python3 --version
    Python 3.7.0

Then I have checked update-alternatives configuration:

sudo update-alternatives --config python3
There are 3 choices for the alternative python3 (providing /usr/bin/python3).

  Selection    Path                                        Priority   Status
------------------------------------------------------------
  0            /usr/local/bin/python3.7                     2         auto mode
  1            /<HOME_DIR>/Software/anaconda3/bin/python3   1         manual mode
* 2            /usr/bin/python3.6                           1         manual mode
  3            /usr/local/bin/python3.7                     2         manual mode

Then I have checked location of the python3:

which python3
/usr/local/bin/python3

Then I have checked PATH:

echo $PATH
/usr/lib/x86_64-linux-gnu/dbus-1.0/include:/usr/local/lib/boost/include:/<HOME_DIR>/bin:/<HOME_DIR>/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/<HOME_DIR>/.dotnet/tools

Turns out that python3 has found in /usr/local/bin before the searching in /usr/bin

Why update-alternatives has not created the link in /usr/local/bin for maintaining for proper searching of application ?

I do not want to remove python3 from /usr/local/bin, but in this case update-alternatives becomes useless

How to fix it that update-alternatives create links also in /usr/local/bin ?

1

To answer your first question

Why update-alternatives has not created the link in /usr/local/bin for maintaining for proper searching of application ?

This is simply because alternatives for python3 is configured at the moment to create the symbolic link in /usr/bin. From your output above:

sudo update-alternatives --config python3
There are 3 choices for the alternative python3 (providing /usr/bin/python3).
...

It pretty normal for any Linux distribution to search /usr/local/bin before /usr/bin for executables, as this gives you the freedom to put any binaries and libraries into /usr/local without interfering with the dpkg packages.

For you specific problem and from the output of sudo update-alternatives --config python3 I guess /usr/local/bin/python3 is a symbolic link to /usr/local/bin/python3.7

root@host:~# ls -l /usr/local/bin/python3
lrwxrwxrwx 1 root root 25 Sep 22 15:36 /usr/local/bin/python3 -> /usr/local/bin/python3.7

If that is the case, just remove the symbolic link /usr/local/bin/python3 and you should be fine, since when calling python3 only /usr/bin/python3 is found, which should point to /etc/alternatives/python3 which in turn should point to the selected binary.
If /usr/local/bin/python3 is not a symbolic link, rename it and configure update-alternatives appropriately.

While this might save you for now, the next update might render your configuration useless again. The symbolic link /usr/bin/python3 is shipped with the package python3-minimal and by managing this link with update-alternatives the symbolic link is broken from the view of the python3-minimal package. The next update of this package could fix this problem, but then the link is broken from the view of update-alternatives.

To come around both problems, it would be better to configure update-alternatives to use /usr/local/bin/python3 as the symbolic link providing the selected version.
To do so, the steps as follows should do the trick, including fixing the /usr/bin/python3 link.

sudo update-alternatives --install /usr/local/bin/python3 python3 /usr/bin/python3.6 2
apt-get install --reinstall python3-minimal
  • As I understood I should not put anything in /usr/bin, it is the system responsibility to maintain proper links in this directory ? – Denis Kotov Sep 23 '18 at 6:29
  • Yes correct. Directories like /usr/bin, /usr/lib*, /usr/sbin, ... should not be touched by the admin and /usr/local should be used instead. The corresponding folders in /usr/local are provided by the distribution but are not used by dpkg packages. You can also read up the Linux Filesystem Hierarchy Standard. – Thomas Sep 23 '18 at 8:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.