update-alternatives does not work due to /usr/local/bin precedence
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
Related videos on Youtube
Denis Kotov
Some of my recent personal projects: ICC - Inter Component Communication (C++ Library/Framework) for Thread Safe Component oriented architecture. Very powerful library, take a look at examples folder ;)
Updated on September 18, 2022Comments
-
Denis Kotov almost 2 years
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 ?
-
Denis Kotov almost 6 yearsAs I understood I should not put anything in /usr/bin, it is the system responsibility to maintain proper links in this directory ?
-
Thomas almost 6 yearsYes 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.