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

Hello Andrei -

Thanks for your email...

On Wed, 11 Jan 2023 09:42:38 +0300, 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.

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