Am 17.01.21 um 13:48 schrieb Axel Braun:
Hi Dominique,
Am Donnerstag, 14. Januar 2021, 10:28:28 CET schrieb Dominique Leuenberger / DimStar:
as the planned future can't impact your present until the future becomes present, there must be something different going on at yours. as said, I could fortunately not reproduce it
python 3.8 (the default at this time) provides a /usr/bin/python3 symlink; if that is missing at yours, try "zypper in --force python38- base" Here is how it looks on a fresh TW installation (from 11.01., dup'ed today):
lrwxrwxrwx 1 root root 9 8. Okt 2019 /usr/bin/python3 -> python3.7 -rwxr-xr-x 2 root root 14488 8. Okt 2019 /usr/bin/python3.7 -rwxr-xr-x 2 root root 14488 8. Okt 2019 /usr/bin/python3.7m -rwxr-xr-x 1 root root 14488 29. Nov 12:51 /usr/bin/python3.8
How "fresh" is your TW install if it still ships python3-base with Python 3.7?
Thats kinda surprise, as not the latest python is considered. Running the forced installation showed among others: File /usr/bin/python3 from install of python38-base-3.8.6-2.1.x86_64 (Haupt-Repository (OSS)) conflicts with file from package python3-base-3.7.3-1.4.x86_64 (@System)
which probably explains the above settings, as python3 is linked to python3.7. I did not expect I need allow-vendor-change on dup?
More, I did ot find an option to use update-alternatives for python. That makes live difficult...
python38-base does not use update-alternatives for /usr/bin/python3. Only the primary interpreted shall provide it. Did it use u-a in python 3.7 times? That might explain the update issue. Removing u-a links needs to execute the %postun scripts at the right time. Ben