On Fri, 2022-06-24 at 12:29 +0200, Werner Flamme wrote:
Am 2022-06-24 um 12:12 schrieb Richard Brown:
A more nuanced point of course would be to realise that, if ALP delivers on even a minority of it's stated goals, with everything containerised the problems Axel is finding with Leap would no longer apply, because people should be able to mix and match containers from various codestreams..
Yes, but ALP is not planned to be active in SLE/Leap 15, is it? But SLE/Leap 15 still has some time to go, and having e. g. an ancient python base does not help anyone. And as far as I understand this, Axel is considering SLE/Leap 15.
SLE 15 has a way to go, with a currently advertised end-of-life being 6 years from now (31 July 2028) and an extended LTSS end of life being 3 years after that (31 July 2031) Leap 15 doesn't have nearly as long to go, something like 2.5 years from now dependant on the release of SLE 15 SP5 and ALP As Leap 15.5 is going to be the last Leap, surely you can see the argument that expending extra effort on it would not be as worthwhile as directing that energy to something that will last longer?
* users of SLE 15 (and Leap 15) have to make sure that their locally needed python software is backwards compatible to the old base * maintainers of python packages have to care about the backwards compatibility as well when upstream moves on
Wouldn't it be less work if python base was updated to a recent version, since the current versions of python software already support that version? The maintaners have less backporting work to do. Or, as I see with SLE 15.4, there is a Python3 module now parallel to the already existing Python2 module, and it contains a newer base, hooray!
Users of SLE pay for SLE under the premise that core libraries will not change in any meaningful functional way during the lifespan of the distribution. Something built on the GA version of SLE 15 should continue to work, ideally without recompilation, on all subsequent service packs. I'm sure people will point out exceptions to this premise, and that's fine, businesses don't exactly operate well when adhering to absolutes.. but, given that core premise of SLE 15 I think it's very unlikely you'll see SLE 15 SP5 introducing a new OS python version. Especially when SLE 15 SP5 will not be a feature-heavy release. I could maybe see SUSE coming up with some solutions to that problem for SLE for SLE 15 SP6, but, with the announcement that Leap 15.5 will be the last planned Leap release, there is no suggestion of there ever being a Leap 15.6 based on that SLE 15 SP6.