On Tuesday, January 10, 2023 10:55 AM, J Leslie Turriff wrote:
On Tuesday, January 10, 2023 10:55 AM, J Leslie Turriff wrote:
On 2023-01-09 16:38:34 Glen Barney wrote:
Attempts to install Python 3.10 [alongside Pythong 3.9] fail, with what appear to be dependency conflicts against Python 3.9, as shown: Problem: the installed python39-setuptools-44.1.1-7.3.1.noarch requires 'python39', but this requirement cannot be provided not installable providers: python39-3.9.10-150300.4.8.2.x86_64[repo-oss] python39-3.9.10-150300.4.8.2.x86_64[repo-sle-update] python39-3.9.13-150300.4.13.1.x86_64[repo-sle-update] python39-3.9.14-150300.4.16.1.x86_64[repo-sle-update] Solution 1: You can lock Python39 with the Package Lock capabilities of zypper. info zypper says, Package Locks Management Package locks serve the purpose of preventing changes to the set of installed
On 2023-01-10 16:56:19 Glen Barney wrote: packages on the system. Locks are stored as queries in /etc/zypp/locks file (see also locks(5)). Packages matching a query are then forbidden to change their installed status; an installed package can't be removed or upgraded, not installed package can't be installed. When requesting to install, upgrade or remove such locked package, you will get a dependency problem dialog. (I haven't used this myself, but others on the list have talked about it.)
Thanks for this, but alas as the quoted text hints, I get dependency dialog issues on that as well: # zypper al 'python39*' Specified lock has been successfully added. # zypper ll # | Name | Type | Repository | Comment --+--------------------------+---------+------------+-------- 1 | python39* | package | (any) | # zypper in python310 Loading repository data... Reading installed packages... Resolving package dependencies... Problem: the to be installed python310-3.10.8-150400.4.15.1.x86_64 obsoletes 'python39' provided by the installed python39-3.9.15-150300.4.21.1.x86_64 Solution 1: Following actions will be done: remove lock to allow removal of python39-3.9.15-150300.4.21.1.x86_64 remove lock to allow removal of python39-base-3.9.15-150300.4.21.1.x86_64 remove lock to allow removal of python39-dbm-3.9.15-150300.4.21.1.x86_64 remove lock to allow removal of python39-testsuite-3.9.15-150300.4.21.1.x86_64 remove lock to allow removal of python39-tk-3.9.15-150300.4.21.1.x86_64 remove lock to allow removal of python39-pip-20.2.4-7.8.1.noarch remove lock to allow removal of python39-tools-3.9.15-150300.4.21.1.x86_64 deinstallation of libpython3_9-1_0-3.9.15-150300.4.21.1.x86_64 Solution 2: do not install python310-3.10.8-150400.4.15.1.x86_64 Choose from above solutions by number or cancel [1/2/c/d/?] (c): In this situation, it becomes more clear that Python310 packages REQUIRE the removal of Python39 - which is, as far as I can tell, the core issue. As far as I can tell, they "should not" require that - but they do. There is that rule "Python310 obsoletes Python39" - but that should not be the case? Glen