Home / ubuntu / Questions / 1077481
Accepted
Denis Kotov
Asked: 2018-09-23 05:12:25 +0800 CST

update-alternatives does not work due to /usr/local/bin precedence

  • 772

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 ?

environment-variables 18.04 update-alternatives

1 Answers

  1. Best Answer

    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
    • 5