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 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 Wed, Jan 11, 2023 at 8:29 AM Glen Barney 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 - 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.

On Thu, 12 Jan 2023 00:12:25 +0000 Glen Barney 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 1/11/23 17:12, Andrei Borzenkov wrote:

On Wed, Jan 11, 2023 at 8:29 AM Glen Barney 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

- 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 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 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.

On 1/12/23 17:19, Andrei Borzenkov wrote:

On Thu, Jan 12, 2023 at 8:56 AM Simon Lees 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 1/12/23 17:10, Andrei Borzenkov wrote:

On Thu, Jan 12, 2023 at 8:56 AM Simon Lees 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 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