Leap 15.4 - Installing Python 3.10 alongside Python 3.9
I have a number of 15.4 servers, which have been upgraded from previous recent Leap versions. These servers have the legacy Python 2.7, the current Python 3.6, and the newer Python 3.9 package groups all installed, side by side, and all working properly. However.... attempts to install Python 3.10 fail, with what appear to be dependency conflicts against Python 3.9, as shown: # zypper install python310 Loading repository data... Reading installed packages... Resolving package dependencies... 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: Following actions will be done: deinstallation of python39-setuptools-44.1.1-7.3.1.noarch deinstallation of python39-pip-20.2.4-7.8.1.noarch 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 Solution 3: break python39-setuptools-44.1.1-7.3.1.noarch by ignoring some of its dependencies I have even tried downloading the 8 "main" Python310 packages and installing via rpm... libpython3_10-1_0-3.10.8-150400.4.15.1.x86_64.rpm python310-3.10.8-150400.4.15.1.x86_64.rpm python310-base-3.10.8-150400.4.15.1.x86_64.rpm python310-curses-3.10.8-150400.4.15.1.x86_64.rpm python310-dbm-3.10.8-150400.4.15.1.x86_64.rpm python310-devel-3.10.8-150400.4.15.1.x86_64.rpm python310-pip-22.0.4-150400.3.3.1.noarch.rpm python310-setuptools-57.4.0-150400.2.14.noarch.rpm # rpm -Uvh [lp]* error: Failed dependencies: python39 is needed by (installed) python39-setuptools-44.1.1-7.3.1.noarch python39 = 3.9.15 is needed by (installed) python39-tk-3.9.15-150300.4.21.1.x86_64 python39 = 3.9.15 is needed by (installed) python39-testsuite-3.9.15-150300.4.21.1.x86_64 python(abi) = 3.9 is needed by (installed) python39-setuptools-44.1.1-7.3.1.noarch python(abi) = 3.9 is needed by (installed) python39-pip-20.2.4-7.8.1.noarch python(abi) = 3.9 is needed by (installed) python39-tools-3.9.15-150300.4.21.1.x86_64 python(abi) = 3.9 is needed by (installed) python39-tk-3.9.15-150300.4.21.1.x86_64 python(abi) = 3.9 is needed by (installed) python39-testsuite-3.9.15-150300.4.21.1.x86_64 python39-base >= 3.9.15 is needed by (installed) libpython3_9-1_0-3.9.15-150300.4.21.1.x86_64 python39-base = 3.9.15 is needed by (installed) python39-tools-3.9.15-150300.4.21.1.x86_64 /usr/bin/python3.9 is needed by (installed) python39-setuptools-44.1.1-7.3.1.noarch /usr/bin/python3.9 is needed by (installed) python39-pip-20.2.4-7.8.1.noarch /usr/bin/python3.9 is needed by (installed) python39-tools-3.9.15-150300.4.21.1.x86_64 I've listed out the contents of the existing Python3.9 packages, as well as the manually-downloaded Python3.10 packages. All seem to be properly structured, in that they all install with separate names and/or in separate directories, just as expected. Nevertheless it appears that any attempts to install Python3.10 make the servers try to uninstall Python3.9, which implies that, despite the separate layouts and structures, the two versions cannot be installed side-by-side. I'm sure I am missing something obvious. Can anyone please help me get Python 3.10 deployed alongside Python 3.9 (and the other versions) on Leap 15.4? Thank you! Glen
On 2023-01-09 16:38:34 Glen Barney wrote:
|I have a number of 15.4 servers, which have been upgraded from previous | recent Leap versions. These servers have the legacy Python 2.7, the | current Python 3.6, and the newer Python 3.9 package groups all | installed, side by side, and all working properly. | |However.... attempts to install Python 3.10 fail, with what appear to be | dependency conflicts against Python 3.9, as shown: | |# zypper install python310 |Loading repository data... |Reading installed packages... |Resolving package dependencies... |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: | Following actions will be done: | deinstallation of python39-setuptools-44.1.1-7.3.1.noarch | deinstallation of python39-pip-20.2.4-7.8.1.noarch | 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 | Solution 3: break python39-setuptools-44.1.1-7.3.1.noarch by ignoring | some of its dependencies | |I have even tried downloading the 8 "main" Python310 packages and | installing via rpm... | |libpython3_10-1_0-3.10.8-150400.4.15.1.x86_64.rpm |python310-3.10.8-150400.4.15.1.x86_64.rpm |python310-base-3.10.8-150400.4.15.1.x86_64.rpm |python310-curses-3.10.8-150400.4.15.1.x86_64.rpm |python310-dbm-3.10.8-150400.4.15.1.x86_64.rpm |python310-devel-3.10.8-150400.4.15.1.x86_64.rpm |python310-pip-22.0.4-150400.3.3.1.noarch.rpm |python310-setuptools-57.4.0-150400.2.14.noarch.rpm | |# rpm -Uvh [lp]* |error: Failed dependencies: | python39 is needed by (installed) | python39-setuptools-44.1.1-7.3.1.noarch python39 = 3.9.15 is needed by | (installed) python39-tk-3.9.15-150300.4.21.1.x86_64 python39 = 3.9.15 is | needed by (installed) python39-testsuite-3.9.15-150300.4.21.1.x86_64 | python(abi) = 3.9 is needed by (installed) | python39-setuptools-44.1.1-7.3.1.noarch python(abi) = 3.9 is needed by | (installed) python39-pip-20.2.4-7.8.1.noarch python(abi) = 3.9 is needed | by (installed) python39-tools-3.9.15-150300.4.21.1.x86_64 python(abi) = | 3.9 is needed by (installed) python39-tk-3.9.15-150300.4.21.1.x86_64 | python(abi) = 3.9 is needed by (installed) | python39-testsuite-3.9.15-150300.4.21.1.x86_64 python39-base >= 3.9.15 is | needed by (installed) libpython3_9-1_0-3.9.15-150300.4.21.1.x86_64 | python39-base = 3.9.15 is needed by (installed) | python39-tools-3.9.15-150300.4.21.1.x86_64 /usr/bin/python3.9 is needed | by (installed) python39-setuptools-44.1.1-7.3.1.noarch /usr/bin/python3.9 | is needed by (installed) python39-pip-20.2.4-7.8.1.noarch | /usr/bin/python3.9 is needed by (installed) | python39-tools-3.9.15-150300.4.21.1.x86_64 | |I've listed out the contents of the existing Python3.9 packages, as well | as the manually-downloaded Python3.10 packages. All seem to be properly | structured, in that they all install with separate names and/or in | separate directories, just as expected. Nevertheless it appears that | any attempts to install Python3.10 make the servers try to uninstall | Python3.9, which implies that, despite the separate layouts and | structures, the two versions cannot be installed side-by-side. | |I'm sure I am missing something obvious. Can anyone please help me get | Python 3.10 deployed alongside Python 3.9 (and the other versions) on | Leap 15.4? | |Thank you! |Glen
If, as you say, there are no collisions between the 3.9 and 3.10 packages, perhaps | # zypper --force install ... might do the trick? Leslie -- Platform: Linux Distribution: openSUSE Leap 15.4 x86_64
On Tuesday, January 10, 2023 10:55 AM, J Leslie Turriff wrote:
On 2023-01-09 16:38:34 Glen Barney wrote:
I have a number of 15.4 servers, which have been upgraded from previous recent Leap versions. These servers have the legacy Python 2.7, the current Python 3.6, and the newer Python 3.9 package groups all installed, side by side, and all working properly. However.... attempts to install Python 3.10 fail, with what appear to be dependency conflicts against Python 3.9, as shown: # zypper install python310 Loading repository data... Reading installed packages... Resolving package dependencies... 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: Following actions will be done: deinstallation of python39-setuptools-44.1.1-7.3.1.noarch deinstallation of python39-pip-20.2.4-7.8.1.noarch 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 Solution 3: break python39-setuptools-44.1.1-7.3.1.noarch by ignoring some of its dependencies I'm sure I am missing something obvious. Can anyone please help me get Python 3.10 deployed alongside Python 3.9 (and the other versions) on Leap 15.4? Thank you! Glen
If, as you say, there are no collisions between the 3.9 and 3.10 packages, perhaps # zypper --force install ... might do the trick? Leslie
Leslie - Thank you so much for your reply. Alas, the force flag did not help: # zypper install --force python310 Retrieving repository 'Update repository with updates from SUSE Linux Enterprise 15'[done] Building repository 'Update repository with updates from SUSE Linux Enterprise 15' c[done] Loading repository data... Reading installed packages... Forcing installation of 'python310-3.10.8-150400.4.15.1.x86_64' from repository 'Update repository with updates from SUSE Linux Enterprise 15'. Resolving package dependencies... 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: Following actions will be done: deinstallation of python39-setuptools-44.1.1-7.3.1.noarch deinstallation of python39-pip-20.2.4-7.8.1.noarch 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 Solution 3: break python39-setuptools-44.1.1-7.3.1.noarch by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): I think the problem is not so much with installing 310 as it is with the apparently-required removal of 39, and the breakages that such removals would entail. Ideally I'd like to install 310 without removing 39 (and without breaking the 39 deployment in the process.) I'm confused as to why there is so much insistence in these packages that 39 must be removed before 310 can be installed... and don't know how to tell zypper "Install all the 310 packages without removing 39 please!" And of course, I still feel like it should not be necessary to do that the 310 packages should install alongside all the others, as, well, all the others already do. Any ideas from you and/or anyone on this list would be most appreciated! Thanks, Glen
On 2023-01-10 16:56:19 Glen Barney wrote:
On Tuesday, January 10, 2023 10:55 AM, J Leslie Turriff wrote:
On 2023-01-09 16:38:34 Glen Barney wrote:
I have a number of 15.4 servers, which have been upgraded from previous recent Leap versions. These servers have the legacy Python 2.7, the current Python 3.6, and the newer Python 3.9 package groups all installed, side by side, and all working properly. However.... attempts to install Python 3.10 fail, with what appear to be dependency conflicts against Python 3.9, as shown: # zypper install python310 Loading repository data... Reading installed packages... Resolving package dependencies... 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: Following actions will be done: deinstallation of python39-setuptools-44.1.1-7.3.1.noarch deinstallation of python39-pip-20.2.4-7.8.1.noarch 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 Solution 3: break python39-setuptools-44.1.1-7.3.1.noarch by ignoring some of its dependencies I'm sure I am missing something obvious. Can anyone please help me get Python 3.10 deployed alongside Python 3.9 (and the other versions) on Leap 15.4? Thank you! Glen
If, as you say, there are no collisions between the 3.9 and 3.10 packages, perhaps # zypper --force install ... might do the trick? Leslie
Leslie -
Thank you so much for your reply. Alas, the force flag did not help:
# zypper install --force python310 Retrieving repository 'Update repository with updates from SUSE Linux Enterprise 15'[done] Building repository 'Update repository with updates from SUSE Linux Enterprise 15' c[done] Loading repository data... Reading installed packages... Forcing installation of 'python310-3.10.8-150400.4.15.1.x86_64' from repository 'Update repository with updates from SUSE Linux Enterprise 15'. Resolving package dependencies... 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: Following actions will be done: deinstallation of python39-setuptools-44.1.1-7.3.1.noarch deinstallation of python39-pip-20.2.4-7.8.1.noarch 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 Solution 3: break python39-setuptools-44.1.1-7.3.1.noarch by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/c/d/?] (c):
I think the problem is not so much with installing 310 as it is with the apparently-required removal of 39, and the breakages that such removals would entail.
Ideally I'd like to install 310 without removing 39 (and without breaking the 39 deployment in the process.) I'm confused as to why there is so much insistence in these packages that 39 must be removed before 310 can be installed... and don't know how to tell zypper "Install all the 310 packages without removing 39 please!"
And of course, I still feel like it should not be necessary to do that the 310 packages should install alongside all the others, as, well, all the others already do.
Any ideas from you and/or anyone on this list would be most appreciated!
Thanks, Glen
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 | 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.) Leslie -- Platform: Linux Distribution: openSUSE Leap 15.4 x86_64
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
On Wed, Jan 11, 2023 at 8:29 AM Glen Barney <gn56@hotmail.com> wrote: ....
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.
Tue Feb 15 23:05:55 UTC 2022 - Matej Cepl <mcepl@suse.com> - bsc#1195831 Obsolete older "most modern" versions of python packages (python39 for python310 and so forth). For next versions it is necessary just to edit the macro.
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?
https://bugzilla.opensuse.org/show_bug.cgi?id=1195831 You are not authorized to access bug #1195831. Welcome to the community distribution.
Hello Andrei - Thanks for your email... On Wed, 11 Jan 2023 09:42:38 +0300, Andrei Borzenkov <arvidjaar@gmail.com> wrote: >On Wed, Jan 11, 2023 at 8:29 AM Glen Barney <gn56@hotmail.com> wrote: >> 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. >Tue Feb 15 23:05:55 UTC 2022 - Matej Cepl <mcepl@suse.com> >- bsc#1195831 Obsolete older "most modern" versions of python > packages (python39 for python310 and so forth). For next > versions it is necessary just to edit the macro. I apologize, could I get some additional details on "edit the macro?" My goal here is simply to be able to install Python310 alongside the other versions, but the RPMs appear to prevent that quite aggressively. I know how to unpack and repack an RPM, but I am not familiar with "the macro" but if there is an edit I can make to the RPM to solve this I would love to understand what to do! >> 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? >https://bugzilla.opensuse.org/show_bug.cgi?id=1195831 >You are not authorized to access bug #1195831. >Welcome to the community distribution. I apologize, I'm not able to parse this. I tried to go to that link, but got the "not authorized" message. I'm not sure why the public are not allowed to view bugs, but perhaps I am just ignorant of Suse's way of doing things? Would you or someone here be willing to paste in for me the appropriate info from this bug so that I can read it? And/or any other clues would be gratefully appreciated. Thank you! Glen
On Thu, 12 Jan 2023 00:12:25 +0000 Glen Barney <gn56@hotmail.com> wrote:
https://bugzilla.opensuse.org/show_bug.cgi?id=1195831 You are not authorized to access bug #1195831. Welcome to the community distribution.
I apologize, I'm not able to parse this. I tried to go to that link, but got the "not authorized" message. I'm not sure why the public are not allowed to view bugs, but perhaps I am just ignorant of Suse's way of doing things? Would you or someone here be willing to paste in for me the appropriate info from this bug so that I can read it?
Don't worry, that's just Andrei's way of having a quiet moan about inappropriate permission settings on bug reports. It's not your ignorance, it's some Suse people's incompetence, or possibly mendacity. It's possible there might be somebody here who can read it I suppose :)
On Thu, 12 Jan 2023 16:39:25 -0800 Dave Howorth wrote:
You are not authorized to access bug #1195831. Welcome to the community distribution. I apologize, I'm not able to parse this. I tried to go to that link, Don't worry, that's just Andrei's way of having a quiet moan about inappropriate permission settings on bug reports. It's not your ignorance, it's some Suse people's incompetence, or possibly mendacity. It's possible there might be somebody here who can read it I suppose :)
Ah. Understood. Thank you! Glen
On 1/12/23 11:09, Dave Howorth wrote:
On Thu, 12 Jan 2023 00:12:25 +0000 Glen Barney <gn56@hotmail.com> wrote:
https://bugzilla.opensuse.org/show_bug.cgi?id=1195831 You are not authorized to access bug #1195831. Welcome to the community distribution.
I apologize, I'm not able to parse this. I tried to go to that link, but got the "not authorized" message. I'm not sure why the public are not allowed to view bugs, but perhaps I am just ignorant of Suse's way of doing things? Would you or someone here be willing to paste in for me the appropriate info from this bug so that I can read it?
Don't worry, that's just Andrei's way of having a quiet moan about inappropriate permission settings on bug reports. It's not your ignorance, it's some Suse people's incompetence, or possibly mendacity.
As with many fun things in life, its a Legacy software issue. Currently we are still using a bugzilla instance from the Novell era. It has some unfortunate settings that are very hard to change, many that any bug thats listed for SUSE Partners becomes closed. That bugzilla instance has so many patches that its very hard to work on or update. In the mean time there is an ongoing project to replace it with a more maintainable bugzilla instance. Which combined with changes to policy around ALP will hopefully mean that the only tickets that end up private are the ones containing SUSE Customer information.
It's possible there might be somebody here who can read it I suppose :)
Yes I do still read this list on occasion and I have been given permission to share info from confidential bugs as long as it doesn't include customer info. You can also email bugshare@lists.opensuse.org and I should see the request, but i'm only one person so I probably won't respond if people spam the list too heavily. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 1/11/23 17:12, Andrei Borzenkov wrote:
On Wed, Jan 11, 2023 at 8:29 AM Glen Barney <gn56@hotmail.com> wrote: ....
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.
Tue Feb 15 23:05:55 UTC 2022 - Matej Cepl <mcepl@suse.com>
- bsc#1195831 Obsolete older "most modern" versions of python packages (python39 for python310 and so forth). For next versions it is necessary just to edit the macro.
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?
https://bugzilla.opensuse.org/show_bug.cgi?id=1195831 You are not authorized to access bug #1195831.
Welcome to the community distribution.
Bug 1195831 - python310 doesn't offer a migration path With the submitted python310 in Staging there is no submission path offered to do a removal of python39 and replace it with the newer version. This would lead to an orphaned package on migrations and customers not receiving the newer python310. I don't think that python310 can follow the guidelines and do a Provides and Obsoletes. An alternative might be to introduce a meta package for this development interpreter like it is done for rust: https://build.suse.de/package/view_file/SUSE:SLE-15-SP4:GA/rust/rust.spec?ex... or introducing a python39-obsolete, which Recommends the installation of python310. There might be other solutions to this as well, but we definitely require some fix for this migration/orphaned package issue. ------------------------------------------------------------------- An obsolete is not a conflict however, so this change doesn't explain them not being co install-able. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Thu, Jan 12, 2023 at 8:56 AM Simon Lees <sflees@suse.de> wrote:
An obsolete is not a conflict however, so this change doesn't explain them not being co install-able.
Obsolete is implicit conflict. Package A obsoletes package B means that when you install package A the package B must be uninstalled. Because A replaces B.
On 1/12/23 17:10, Andrei Borzenkov wrote:
On Thu, Jan 12, 2023 at 8:56 AM Simon Lees <sflees@suse.de> wrote:
An obsolete is not a conflict however, so this change doesn't explain them not being co install-able.
Obsolete is implicit conflict. Package A obsoletes package B means that when you install package A the package B must be uninstalled. Because A replaces B.
I always presumed it did it in a "Soft" way, I gues I am wrong. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Thu, Jan 12, 2023 at 8:56 AM Simon Lees <sflees@suse.de> wrote: ...
Bug 1195831 - python310 doesn't offer a migration path
With the submitted python310 in Staging there is no submission path offered to do a removal of python39 and replace it with the newer version. This would lead to an orphaned package on migrations and customers not receiving the newer python310.
Sorry, but it does not explain *why* python39 must be removed and what prevents both versions to coexist. Sounds like a pure management decision.
On 1/12/23 17:19, Andrei Borzenkov wrote:
On Thu, Jan 12, 2023 at 8:56 AM Simon Lees <sflees@suse.de> wrote: ...
Bug 1195831 - python310 doesn't offer a migration path
With the submitted python310 in Staging there is no submission path offered to do a removal of python39 and replace it with the newer version. This would lead to an orphaned package on migrations and customers not receiving the newer python310.
Sorry, but it does not explain *why* python39 must be removed and what prevents both versions to coexist. Sounds like a pure management decision.
Don't shoot the messenger, that's just the content of the bugreport. At a guess i'd say its related to the way someone would like it to be implemented for package hub as they are probably using the same package. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 2023-01-12 00:52:53 Simon Lees wrote:
|On 1/12/23 17:19, Andrei Borzenkov wrote: |> On Thu, Jan 12, 2023 at 8:56 AM Simon Lees <sflees@suse.de> wrote: |> ... |> |>> Bug 1195831 - python310 doesn't offer a migration path |>> |>> With the submitted python310 in Staging there is no submission path |>> offered to do a removal of python39 and replace it with the newer |>> version. This would lead to an orphaned package on migrations and |>> customers not receiving the newer python310. |> |> Sorry, but it does not explain *why* python39 must be removed and what |> prevents both versions to coexist. Sounds like a pure management |> decision. | |Don't shoot the messenger, that's just the content of the bugreport. At |a guess i'd say its related to the way someone would like it to be |implemented for package hub as they are probably using the same package.
Whoever decided to set it up this way obviously didn't think about migration testing or multiple server support, where both versions need to be available. Leslie -- Platform: Linux Distribution: openSUSE Leap 15.4 x86_64
On 1/12/23 17:30, J Leslie Turriff wrote:
On 2023-01-12 00:52:53 Simon Lees wrote:
|On 1/12/23 17:19, Andrei Borzenkov wrote: |> On Thu, Jan 12, 2023 at 8:56 AM Simon Lees <sflees@suse.de> wrote: |> ... |> |>> Bug 1195831 - python310 doesn't offer a migration path |>> |>> With the submitted python310 in Staging there is no submission path |>> offered to do a removal of python39 and replace it with the newer |>> version. This would lead to an orphaned package on migrations and |>> customers not receiving the newer python310. |> |> Sorry, but it does not explain *why* python39 must be removed and what |> prevents both versions to coexist. Sounds like a pure management |> decision. | |Don't shoot the messenger, that's just the content of the bugreport. At |a guess i'd say its related to the way someone would like it to be |implemented for package hub as they are probably using the same package.
Whoever decided to set it up this way obviously didn't think about migration testing or multiple server support, where both versions need to be available.
It is highly probable that package hub is only supporting one additional python version per release so it isn't an issue, openSUSE is still only supporting 3.6 in Leap 15.4 -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Wednesday, January 11, 2023 10:49 PM, Andrei Borzenkov wrote:
Sorry? The whole point is to have both versions at the same time.
Correct. I'm sorry that I failed to make that more clear. We need - and I would argue many developers working on Python would need - 3.9 and 3.10 (and future versions) installed side-by-side, same server, same time. Interestingly that IS the case for python 2.7 and python 3.6. I have a machine with 2.7, 3.6, and 3.9 all installed together. So I cannot see any reason why 3.10 should not also work.
Sorry, but it does not explain *why* python39 must be removed and what prevents both versions to coexist. Sounds like a pure management decision.
Apologies if I am treading in areas I should not, but this does make me wonder: If this is in fact a management decision, is it possible to reach those managers and ask them to reconsider/change this? Glen
On 1/12/23 17:24, Glen Barney wrote:
On Wednesday, January 11, 2023 10:49 PM, Andrei Borzenkov wrote:
Sorry? The whole point is to have both versions at the same time.
Correct. I'm sorry that I failed to make that more clear. We need - and I would argue many developers working on Python would need - 3.9 and 3.10 (and future versions) installed side-by-side, same server, same time.
Interestingly that IS the case for python 2.7 and python 3.6. I have a machine with 2.7, 3.6, and 3.9 all installed together. So I cannot see any reason why 3.10 should not also work.
Most developers are using openSUSE Tumbleweed where Python 3.8, 3.9 and 3.10 are all co install-able and there is a different mechanism to set the default python and handle migrations. This was done post the release of Leap 15, so it was never implemented there and 3.6 will remain the default because that is what we promised SUSE customers. I expect that ALP will have a similar setup to tumbleweed and handling multiple python versions will be easier.
Sorry, but it does not explain *why* python39 must be removed and what prevents both versions to coexist. Sounds like a pure management decision.
Apologies if I am treading in areas I should not, but this does make me wonder: If this is in fact a management decision, is it possible to reach those managers and ask them to reconsider/change this?
Python 3.9 and 3.10 have never been officially supported in Leap 15.4 (I believe there are plans to have atleast one for 15.5) so if this was done to make package hub work properly for SUSE it will be hard to convince them to change it again. On the other hand branching the package and removing the conflicts and building a version for yourself is not hard. I can probably help walk you through the process a little later. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 1/10/23 09:08, Glen Barney wrote:
I have a number of 15.4 servers, which have been upgraded from previous recent Leap versions. These servers have the legacy Python 2.7, the current Python 3.6, and the newer Python 3.9 package groups all installed, side by side, and all working properly.
However.... attempts to install Python 3.10 fail, with what appear to be dependency conflicts against Python 3.9, as shown:
# zypper install python310 Loading repository data... Reading installed packages... Resolving package dependencies... 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: Following actions will be done: deinstallation of python39-setuptools-44.1.1-7.3.1.noarch deinstallation of python39-pip-20.2.4-7.8.1.noarch 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 Solution 3: break python39-setuptools-44.1.1-7.3.1.noarch by ignoring some of its dependencies
I have even tried downloading the 8 "main" Python310 packages and installing via rpm...
libpython3_10-1_0-3.10.8-150400.4.15.1.x86_64.rpm python310-3.10.8-150400.4.15.1.x86_64.rpm python310-base-3.10.8-150400.4.15.1.x86_64.rpm python310-curses-3.10.8-150400.4.15.1.x86_64.rpm python310-dbm-3.10.8-150400.4.15.1.x86_64.rpm python310-devel-3.10.8-150400.4.15.1.x86_64.rpm python310-pip-22.0.4-150400.3.3.1.noarch.rpm python310-setuptools-57.4.0-150400.2.14.noarch.rpm
# rpm -Uvh [lp]* error: Failed dependencies: python39 is needed by (installed) python39-setuptools-44.1.1-7.3.1.noarch python39 = 3.9.15 is needed by (installed) python39-tk-3.9.15-150300.4.21.1.x86_64 python39 = 3.9.15 is needed by (installed) python39-testsuite-3.9.15-150300.4.21.1.x86_64 python(abi) = 3.9 is needed by (installed) python39-setuptools-44.1.1-7.3.1.noarch python(abi) = 3.9 is needed by (installed) python39-pip-20.2.4-7.8.1.noarch python(abi) = 3.9 is needed by (installed) python39-tools-3.9.15-150300.4.21.1.x86_64 python(abi) = 3.9 is needed by (installed) python39-tk-3.9.15-150300.4.21.1.x86_64 python(abi) = 3.9 is needed by (installed) python39-testsuite-3.9.15-150300.4.21.1.x86_64 python39-base >= 3.9.15 is needed by (installed) libpython3_9-1_0-3.9.15-150300.4.21.1.x86_64 python39-base = 3.9.15 is needed by (installed) python39-tools-3.9.15-150300.4.21.1.x86_64 /usr/bin/python3.9 is needed by (installed) python39-setuptools-44.1.1-7.3.1.noarch /usr/bin/python3.9 is needed by (installed) python39-pip-20.2.4-7.8.1.noarch /usr/bin/python3.9 is needed by (installed) python39-tools-3.9.15-150300.4.21.1.x86_64
I've listed out the contents of the existing Python3.9 packages, as well as the manually-downloaded Python3.10 packages. All seem to be properly structured, in that they all install with separate names and/or in separate directories, just as expected. Nevertheless it appears that any attempts to install Python3.10 make the servers try to uninstall Python3.9, which implies that, despite the separate layouts and structures, the two versions cannot be installed side-by-side.
I'm sure I am missing something obvious. Can anyone please help me get Python 3.10 deployed alongside Python 3.9 (and the other versions) on Leap 15.4?
It seems more like there is a conflict in something like python-tools or python-setuptools, maybe you can remove the 3.9 version manually and that will make the resolver happier. On my tumbleweed system I certainly still have both installed but that is setup differently. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On Thu, Jan 12, 2023 at 9:13 AM Simon Lees <sflees@suse.de> wrote: ...
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: Following actions will be done: deinstallation of python39-setuptools-44.1.1-7.3.1.noarch deinstallation of python39-pip-20.2.4-7.8.1.noarch 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 Solution 3: break python39-setuptools-44.1.1-7.3.1.noarch by ignoring some of its dependencies
...
It seems more like there is a conflict in something like python-tools or
Python310 obsoletes python39 so python39 must be uninstalled, but python39-setuptools (and other python39 modules) have explicit requirements for python39.
python-setuptools, maybe you can remove the 3.9 version manually and
Sorry? The whole point is to have both versions at the same time.
participants (5)
-
Andrei Borzenkov -
Dave Howorth -
Glen Barney -
J Leslie Turriff -
Simon Lees