Move to py311 #12
Move to py311 #12
Conversation
The required functionality is provided by the core os library
|
QA images building here: QA package for submission building here: |
There was a problem hiding this comment.
I struggle to follow the spec changes, many macros changed...
By looking the package builds I see it results into a different package name:
SLE-15-SP1 has python3-kiwi-9.24.43
The QA:Maintenance project builds python311-kiwi-9.24.43
Different package name with different provision with the same exact version.... isnt this so confusing? I doubt this is what we want, I might miss some details, but at a glance this looks wrong to me and resulting into two different packages that might conflict to to install both together and that the new one might not be seen as an update from the package manager.
|
@davidcassany Actually this is what we want to achieve. I'm not sure if you have followed the conversation around python in SLES15 but beginning with SLES15-SP5 onwards a full python 3.11 stack exists in combination with the old python 3.6 stack. This gives us finally the opportunity to move kiwi in SLE15 to python 3.11. In order to do this the SLE team has provided new macros to allow an easy way to package python modules in SLES. This is what you see with As a consequence of using the macros the package name changes intentionally So kiwi for python 3.11 in SLES has to be named differently because all old 3.6 builds stays as python3-xxx whereas all 3.11 builds are named python311-xxx. That's how they were able to add the 3.11 stack without breaking anything
Correct and the wanted behavior
different python interpreters on the same distro makes this inevitable. On TW you will see even more of this because there is 310, 311 and 312
nope no conflicts, as they differentiate the binary names and the location of files by the version of the python interpreter. And all this is handled by the macro and fortunately out of my hands, it just worked :) With this background information in mind could you review again ? Thanks much |
Since SLE and Leap has python 3.11 we can now finally move to a newer python version for this target
|
@schaefi thanks much for the explanations.
Oh I see, I did not follow the conversation around python packaging sorry. I see, so correct me if I am wrong, but I understand that both packages py3.6 and py3.11 will be installable together and both will be launched at the same version, at least for the first release. My doubt is what happens from now on for the py3.6 version of it, is it now deprecated? To my understanding with the current change KIWI sources will no longer build py3.6 version of it. I don't have any issue with that setup, just trying to understand maintenance implications of the change.
Yes, this is nice, in fact the spec is significantly simplified in this PR.
👍 All looking good from my side then. As I suspected I just missed many details on the packaging 😅 |
I'm not aiming for two packages (3.6 and 3.11). In fact the changes here will cause the python code to be no longer working with 3.6 because of the other commit where I moved the xattr stuff to os.getxattr which does not exist in 3.6. So when this PR gets merged we move kiwi in SLES to py311 and thinking further I believe we need an Obsoletes: setting in the spec for the old package python3-kiwi. What do you think ?
yes that's what I want to achieve
It's good that you ask all the questions so we can think it through. Thanks much |
Obsolete python3-kiwi which is the version that builds against the old 3.6 stack
Sounds good. I guess this requires some further testing though, I'll try to check if I can easily run a test on Leap 15.6, should be a reasonable OS for testing all this. To my understanding what we want is making the upgrade of kiwi transparent, hence if anyone runs To my eyes this two cases above is what needs to be tested and those require the Obsoletes. I never now by heart how this two RPM spec directives, |
yes exactly
Same here 😄 Thanks much for testing. I have only tested in the QA projects, but that doesn't cover the update scenario you described |
|
Alright these are the results of my tests: Running Running Running So first surprising result, which is probably not that bad (for now), but IMHO not desired, is that some of the subpackages that are not python related are getting mixed (e.g. man pages). Since both are in the same version it should not be a problem and the content should be the same, however, they come from two independent source rpms... I'd say this comes from this lines on the main package: This might not be strict enough as higher versions of kiwi-man-pages are not conflicting. I have no good ideas on how to improve it. I think that making I don't think this is a big issue now, but it might be in later on versions once kiwi py3.11 source code is no longer aligned with kiwi py3.6 package. We don't want that a @schaefi do my tests make sense to you? Have you done some other sort of trials? |
|
@davidcassany Thanks for testing.
I think what we want to test is on a system with python3-kiwi installed and |
Move to python 3.11 stack for SLE/Leap
Since SLE and Leap has python 3.11 we can now finally move to
a newer python version for this target