On 1/7/22 00:39, Axel Braun wrote:
Hello Simon,
Am Donnerstag, 6. Januar 2022, 11:02:51 CET schrieb Simon Lees:
On 1/4/22 00:29, Axel Braun wrote:
Hello Simon,
Am Montag, 3. Januar 2022, 14:47:34 CET schrieb Simon Lees:
The real discussion is about what Python version the system packages have to use.
Yes.
In my case e.g. aehostd is system software. Now try to explain to an auditor that this security relevant system software runs on a unmaintained Python version. Yeah, have fun.
This is simple, the python 3.6 is still maintained just by a different group of people, if significant python 3.6 security issues are found they will be fixed by someone within SUSE, this is a guarantee we give to our customers
Its not just the python 3.6 base packages, as well other packages have to be kept on a version that still runs with 3.6. This is a growing number of packages, as many are dropping support for python 3.6. Who is taking care about them?
For SLE packages SUSE Employees will keep them working, for some openSUSE packages someone in the community will care and do the work and for some others probably no one will care enough to do the work and they will just stay at there existing versions.
And suddenly you are in a chain of dependencies that is hard to follow up on and most likely to break soon.
Not to forget: Security updates. I doubt that packagers are willing (or capable, or have the unpaid time) to patch security fixes into all kinds of outdated packages. So they stay vulerable. Or they can be updated to a newer version, but requires a buch of other packages to be updates as well. I have a real-world example for this, fixed in TW, and pending with the maintenance team for Leap 15.3 since 3 month, as they need to decide: Update other packages as well, or keep the vulnerable version shipped with Leap 15.3
The more I think about it, the more I feel Leap should take a higher speed than SLE, as our users expect a stable base and up-to-date applications. So maybe we leave the outdate SLE stuff in SP3-backports and update the applications into Leap repositories, if that is somehow feasible? New packages to Leap instead of SP3-backports?
Might be possible for "Leaf applications" with smaller dependency chains that work more flexibly with smaller more flexible dependency chains but once you are talking about gnome or kde applications it is far more likely to cause more issues then its worth, to the point where if you end up talking about having different versions of glibc then you wind up with SLE and Leap being basically completely different distributions again. With enough man effort anything is possible but currently I doubt we have the man effort to maintain a third Gnome, KDE or python stack, this lack of man power was one of the main reasons from moving from the older model to the current Leap model. -- 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