Let me start by stating that the following is limited to the Public Cloud SDK packages, i.e. packages that provide code used to access the APIs for Alibaba, AWS, Azure, and Google cloud, no other Python packages are affected by this change.
Also the timing of when you apply these changes is under your control, there is no forced update. There are some support implications and I’ll get to those later.
What is happening?
Contents
A while ago we introduced a Python 3.11 interpreter and module stack in the SLE-Module-Python3 repository for SLE 15 SP4 and later. This does not effect the default system Python which remains as Python 3.6. Meaning /usr/bin/python3 will continue to point to the Python 3.6 interpreter. There are many parts of a SLE system that depend on the link from /usr/bin/python3 to /usr/bin/python3.6 and as such you cannot change this link without breaking parts of your system. While other Python interpreters exist in the SLE-Module-Python3 repository the Python 3.11 interpreter is special in that we are providing a reasonably large set of 400+ Python modules built with the Python 3.11 interpreter. This set is smaller than the modules provided for the default Python 3.6 interpreter but was scoped large enough such that we can move the Public Cloud tool-chains and some other tools forward.
In an effort to provide as smooth a transition as possible and to not switch things out without notification the packages in question, for example python3-boto3 will be set to be Obsoleted in the new packages, python311-boto3. This means that if there are no other RPM dependencies on the old package, i.e. the package starting with python3-, that package will be removed from your system and will be replaced by the new package, i.e. a package that starts with python311-. This will happen silently, i.e. no warning from zypper. Again, the silent change only happens when there are no other RPM dependencies.
The practical effect of this is that any script that is using any of the SDK modules has to be re-pointed to the Python 3.11 interpreter, i.e. #!/usr/bin/python3 needs to change to #!/usr/bin/python3.11. That’s it.
Said differently, if you get a “module not found error” after a system update when you are running one of your scripts that uses any of the Public Cloud SDKs check your “#!” line and adjust it. Once you re-point your script to #!/usr/bin/python3.11 the error will go away and you are good to go.
If you package your own code as RPM packages and have the appropriate dependencies set in your spec file zypper will notify you of a conflict.
In cases where there are RPM dependencies on the Python 3.6 based packages you will get a message from zypper about a conflict and you need to choose how to resolve the conflict.
If you have the cli packages installed, for example azure-cli or aws-cli, those code bases have also been switched to the Python 3.11 interpreter and therefore will pull in the new python311-* packages. Since these modules have the Obsoletes directive for the old packages you will be notified if there are unresolvable conflicts. If you have no custom RPMs that generate dependencies the update will proceed without issues and the appropriate packages starting with python3- will be removed.
Why are you doing this to me?
The Python modules for the Public Cloud move at a relatively high speed and all have dropped support for Python 3.6 builds. In an effort to continue to be in a position to provide access to new features in the Public Cloud frameworks we need to be able to update the SDKs. This is only possible if we advance the version of the Python interpreter used to build the SDK, and cli packages.
When is this hitting me?
The updated packages will be available in mid to late April. That said, you get to decide when you switch. There are, at the time of release, no security implications and the new packages will be there for you when you have had time to test your setup against the updated packages. Until then you can use the code built against the Python 3.6 interpreter. The implication is that if you run across a bug it will need to be reproduced with the latest package, as is customary for everything in SLE, and as such that means the Python 3.11 builds.
What are you doing to help me?
We are creating a new support status for our packages, known as superseded. This status indicates to the package management stack that a package with name A has been superseded by a package with name B. The successor information will be encoded in the repository data which is processed by zypper. Therefore zypper will inform you when a package on your system is in the superseded state and zypper will tell you which package to install. This new functionality will be available with the next version of zypper, zypper-1.14.69 and libzypp-17.32.0. The support status of a package is shown when you run zypper info for a package. For example zypper info zypper will show that the package has Level 3 support with the entry labeled Support Level. This will change to superseded for packages that have successor packages. Since zypper will also provide the information of the successor package you are only a zypper in operation away from getting the new packages. The information zypper will provide as part of the package information will look as follows:
-> zypper info foo Support Level : Discontinued and superseded by a different package (bar) The successor package is already installed.
This happens when the successor package is already installed on your system. In some cases the successor package will not remove the predecessor, while in other cases, like the one for the Public Cloud SDKs the predecessor packages will be removed when the successor is installed.
-> zypper info foo Support Level : Discontinued and superseded by a different package (bar) The successor package should be installed as soon as possible to receive continued support.
In this case the successor package is not yet installed and zypper is informing you that the successor package is available and the recommendation is to install it.
-> zypper info foo Support Level : Discontinued and superseded by a different package (wrzlprmpf) Unfortunately the successor package is not provided by any repository.
This is a bug and should be reported. In this case we forgot to publish the successor package or made a mistake in creating the repository metadata.
This is new for SLE, isn’t it?
At the package level it is new, yes. In the Public Cloud we have had the feature of succession for a long time. The data made available on pint.suse.com shows the succession of images. Whenever a new image is released in replacement of an already existing image the new image is the successor image and the previous image is set to be superseded. As such the concept is something we have used at a higher level for over 10 years and we are now bringing this concept to the package level to provide a clear lineage for packages in cases where the new package is not a drop in replacement for and older package but the new package is intended to take the place of the old package.
The bottom line
If you have custom scripts the change is a reasonably easy change to the “#!” line and if you are using the command line tools we ship only you will not even notice the switch to the newer Python interpreter.
