Python 3.6 EOL but still in Leap 15.4
HI! Python 3.6 has reached EOL and various Python module packages already drop support for 3.6. But still Python 3.6 is planned to be shipped with Leap 15.4 instead of a newer version. IMO this does not make sense at all. Ciao, Michael.
On 03/01/2022 09:52, Michael Ströder wrote:
HI!
Python 3.6 has reached EOL and various Python module packages already drop support for 3.6. But still Python 3.6 is planned to be shipped with Leap 15.4 instead of a newer version.
IMO this does not make sense at all.
Ciao, Michael. That is what you get when you base your consumer product on antiquate Enterprise software. It is a feature, not a bug!!
--- Frans.
Hi, Am 03.01.22 um 09:52 schrieb Michael Ströder:
HI!
Python 3.6 has reached EOL and various Python module packages already drop support for 3.6. But still Python 3.6 is planned to be shipped with Leap 15.4 instead of a newer version.
Before this thread develops into the 10th or so discussion about Python versions in Leap and Tumbleweed within the last 12 moths: Please be very specific about your demands and claims. The "instead of a newer version" will immediately be dismissed by the fact that 15.3 already ships the Python 3.9 interpreter in addition to 3.6 and there was once an announcement here on the list that they even want to include Python 3.10 in 15.4. The real discussion is about what Python version the system packages have to use. And because, as I understand it, all 15.X releases need to maintain the binary compatibility of earlier 15 releases, they cannot move away from Python 3.6.
IMO this does not make sense at all.
It's the decision of SUSE and they have to allocate the manpower to support their Enterprise products. I am not sure if the decision makers are really aware of the consequences. As evidenced how the python36 drop in Tumbleweed and the python310 introductions are handled, and the by the increasing number of threads popping up on the mailing lists, reddit posts and so on about Python versions, there is at least a lack of clear communication to the community about it.
Ciao, Michael.
- Ben
On 1/3/22 10:45, Ben Greiner wrote:
Am 03.01.22 um 09:52 schrieb Michael Ströder:
Python 3.6 has reached EOL and various Python module packages already drop support for 3.6. But still Python 3.6 is planned to be shipped with Leap 15.4 instead of a newer version.
Before this thread develops into the 10th or so discussion about Python versions in Leap and Tumbleweed within the last 12 moths: Please be very specific about your demands and claims. The "instead of a newer version" will immediately be dismissed by the fact that 15.3 already ships the Python 3.9 interpreter in addition to 3.6 and there was once an announcement here on the list that they even want to include Python 3.10 in 15.4.
IMO the fact that standard /usr/bin/python3 is not maintained upstream anymore is enough to rule out Python 3.6 in Leap 15.4. The non-standard interpreters 3.9+ are mainly only usable for developing software in virtual envs.
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.
And because, as I understand it, all 15.X releases need to maintain the binary compatibility of earlier 15 releases, they cannot move away from Python 3.6.
And this is set in stone forever? Insisting on using this ancient stuff makes openSUSE *and* SLE look really bad compared to other distros and will cause nothing than grief. Ciao, Michael.
On 1/3/22 21:38, Michael Ströder wrote:
On 1/3/22 10:45, Ben Greiner wrote:
Am 03.01.22 um 09:52 schrieb Michael Ströder:
Python 3.6 has reached EOL and various Python module packages already drop support for 3.6. But still Python 3.6 is planned to be shipped with Leap 15.4 instead of a newer version.
Before this thread develops into the 10th or so discussion about Python versions in Leap and Tumbleweed within the last 12 moths: Please be very specific about your demands and claims. The "instead of a newer version" will immediately be dismissed by the fact that 15.3 already ships the Python 3.9 interpreter in addition to 3.6 and there was once an announcement here on the list that they even want to include Python 3.10 in 15.4.
IMO the fact that standard /usr/bin/python3 is not maintained upstream anymore is enough to rule out Python 3.6 in Leap 15.4. The non-standard interpreters 3.9+ are mainly only usable for developing software in virtual envs.
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
And because, as I understand it, all 15.X releases need to maintain the binary compatibility of earlier 15 releases, they cannot move away from Python 3.6.
And this is set in stone forever?
Forever being atleast the 15.X series where we have promised customers we won't break binary compatibility or remove functionality. Maybe in future SLE versions the model will be different but I am as yet unsure.
Insisting on using this ancient stuff makes openSUSE *and* SLE look really bad compared to other distros and will cause nothing than grief.
I tend to agree with this, although in my eyes the solution is having SLE / Leap 16 available sooner although lots of people might disagree with me for lots of reasons. -- 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
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? Cheers Axel
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. -- 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
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? Cheers Axel
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
On Mon, Jan 3, 2022 at 8:48 AM Simon Lees <sflees@suse.de> wrote:
On 1/3/22 21:38, Michael Ströder wrote:
On 1/3/22 10:45, Ben Greiner wrote:
Am 03.01.22 um 09:52 schrieb Michael Ströder:
Python 3.6 has reached EOL and various Python module packages already drop support for 3.6. But still Python 3.6 is planned to be shipped with Leap 15.4 instead of a newer version.
Before this thread develops into the 10th or so discussion about Python versions in Leap and Tumbleweed within the last 12 moths: Please be very specific about your demands and claims. The "instead of a newer version" will immediately be dismissed by the fact that 15.3 already ships the Python 3.9 interpreter in addition to 3.6 and there was once an announcement here on the list that they even want to include Python 3.10 in 15.4.
IMO the fact that standard /usr/bin/python3 is not maintained upstream anymore is enough to rule out Python 3.6 in Leap 15.4. The non-standard interpreters 3.9+ are mainly only usable for developing software in virtual envs.
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
And because, as I understand it, all 15.X releases need to maintain the binary compatibility of earlier 15 releases, they cannot move away from Python 3.6.
And this is set in stone forever?
Forever being atleast the 15.X series where we have promised customers we won't break binary compatibility or remove functionality. Maybe in future SLE versions the model will be different but I am as yet unsure.
Insisting on using this ancient stuff makes openSUSE *and* SLE look really bad compared to other distros and will cause nothing than grief.
I tend to agree with this, although in my eyes the solution is having SLE / Leap 16 available sooner although lots of people might disagree with me for lots of reasons.
I'd really like to see SLE/Leap 16 sooner rather than later too. The tech debt in SLE 15 is piling up and a lot of stuff that I've done in Tumbleweed for that future SLE version can't be backported because they're foundational things that would make SLE 15 into a different SLE anyway. -- 真実はいつも一つ！/ Always, there's only one truth!
Dne 03. 01. 22 v 10:45 Ben Greiner napsal(a):
It's the decision of SUSE and they have to allocate the manpower to support their Enterprise products. I am not sure if the decision makers are really aware of the consequences. As evidenced how the python36 drop in Tumbleweed and the python310 introductions are handled, and the by the increasing number of threads popping up on the mailing lists, reddit posts and so on about Python versions, there is at least a lack of clear communication to the community about it.
1. We are seriously aware how poorly we communicate our policy decisions about Python, so any specific suggestion what's missing (or any volunteering work on the improvements) are more than welcome. 2. I can assure you that too-slow/too-fast problem is something we are acutely aware of, it is probably one of the biggest problems all Linux distributors are struggling with, but nobody came with really good solution. With every user who is angry with us for moving too fast and upgrading too much, there is at least one user or more who is angry with us for moving too slow and not upgrading enough. Currently, the leading solution seem to lead to heavy use of containers, but then there are already users of containers who are becoming quite aware of problems with maintaining content of those containers, and the circle just continues. 3. The fact of life (and I am not much happy with it personally) is that Python 3 in SLE-15 will be 3.6 (and with the EOL, 3.6.15 now forever). Period. Currently, the policy is that every new service pack of SLE-15 will have also the “latest” interpreter-only Python (3.10 for SP4), which will replace the previous latest version. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Only those laugh of wounds, who never have been hurt. -- despair.com
On Wednesday 2022-01-05 20:32, Matěj Cepl wrote:
3. The fact of life (and I am not much happy with it personally) is that Python 3 in SLE-15 will be 3.6 (and with the EOL, 3.6.15 now forever). Period. Currently, the policy is that every new service pack of SLE-15 will have also the “latest” interpreter-only Python (3.10 for SP4), which will replace the previous latest version.
So, from the point of view of an ISV, one has to rebuild all the Python packages which the distro originally shipped and which a software needs, just to take advantage of the 3.10 interpreter… right?
On 1/5/22 21:18, Jan Engelhardt wrote:
On Wednesday 2022-01-05 20:32, Matěj Cepl wrote:
3. The fact of life (and I am not much happy with it personally) is that Python 3 in SLE-15 will be 3.6 (and with the EOL, 3.6.15 now forever). Period. Currently, the policy is that every new service pack of SLE-15 will have also the “latest” interpreter-only Python (3.10 for SP4), which will replace the previous latest version.
So, from the point of view of an ISV, one has to rebuild all the Python packages which the distro originally shipped and which a software needs, just to take advantage of the 3.10 interpreter… right?
Yes. Or use virtual envs. Which means establishing another pip-compatible repository and whatever build chain you prefer. Given the current situation I really wonder whether it's worth to waste my time with building native openSUSE/SLE packages. Ciao, Michael.
Michael Ströder <michael@stroeder.com> writes:
On 1/5/22 21:18, Jan Engelhardt wrote:
On Wednesday 2022-01-05 20:32, Matěj Cepl wrote:
3. The fact of life (and I am not much happy with it personally) is that Python 3 in SLE-15 will be 3.6 (and with the EOL, 3.6.15 now forever). Period. Currently, the policy is that every new service pack of SLE-15 will have also the “latest” interpreter-only Python (3.10 for SP4), which will replace the previous latest version.
So, from the point of view of an ISV, one has to rebuild all the Python packages which the distro originally shipped and which a software needs, just to take advantage of the 3.10 interpreter… right?
Yes.
Or use virtual envs. Which means establishing another pip-compatible repository and whatever build chain you prefer.
Given the current situation I really wonder whether it's worth to waste my time with building native openSUSE/SLE packages.
I think this is just in line with the current trend that most programming languages are becoming increasingly "hostile"[1] to distribution packaging and Linux distributions are going to end up with shipping the interpreter/runtime and the default package manager only. We already see this with Java and NodeJS, but others are probably going to follow soon. Cheers, Dan Footnotes: [1] not necessarily due to bad intentions -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev
Dne 05. 01. 22 v 21:18 Jan Engelhardt napsal(a):
So, from the point of view of an ISV, one has to rebuild all the Python packages which the distro originally shipped and which a software needs, just to take advantage of the 3.10 interpreter… right?
See how carefully I phrased my original sentence not to promise anything I cannot stand behind. We are currently brainstorming what to do next, but there is no solution yet. Whatever we see so far seems quite expensive in terms of manhours needed. Maintaining two stacks of Python packages so distant from each other as Python 3.6 and 3.10 gets really complicated really quickly. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 A man who won't die for something is not fit to live.
On 1/6/22 10:56, Matěj Cepl wrote:
Dne 05. 01. 22 v 21:18 Jan Engelhardt napsal(a):
So, from the point of view of an ISV, one has to rebuild all the Python packages which the distro originally shipped and which a software needs, just to take advantage of the 3.10 interpreter… right?
See how carefully I phrased my original sentence not to promise anything I cannot stand behind. We are currently brainstorming what to do next, but there is no solution yet. Whatever we see so far seems quite expensive in terms of manhours needed. Maintaining two stacks of Python packages so distant from each other as Python 3.6 and 3.10 gets really complicated really quickly.
Then bite the bullet and simply go for the newer Python release. Anything else is infinitely piling up technical depths and does not have any benefit in real life. Nobody is willing to pay for increasing backporting efforts needed for keeping outdated stuff. It's just that these costs are not really made transparent. Ciao, Michael.
Michael Ströder <michael@stroeder.com> writes:
On 1/6/22 10:56, Matěj Cepl wrote:
Dne 05. 01. 22 v 21:18 Jan Engelhardt napsal(a):
So, from the point of view of an ISV, one has to rebuild all the Python packages which the distro originally shipped and which a software needs, just to take advantage of the 3.10 interpreter… right?
See how carefully I phrased my original sentence not to promise anything I cannot stand behind. We are currently brainstorming what to do next, but there is no solution yet. Whatever we see so far seems quite expensive in terms of manhours needed. Maintaining two stacks of Python packages so distant from each other as Python 3.6 and 3.10 gets really complicated really quickly.
Then bite the bullet and simply go for the newer Python release.
Only because I have a @suse.com email address, doesn't mean that I get to make this call. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev
Dne 06. 01. 22 v 12:21 Michael Ströder napsal(a):
Nobody is willing to pay for increasing backporting efforts needed for keeping outdated stuff. It's just that these costs are not really made transparent.
Sancta simplicitas! Who do you think actually pays real money to SUSE for maintaining SLE? Users of free Leap? Exactly the companies who complain that we upgrade too much. Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 I am a Roman Catholic, so that I do not expect `history' to be anything but a `long defeat' -- though it contains (and in a legend may contain more clearly and movingly) some samples or glimpses of final victory. -- J.R.R. Tolkien
On 1/6/22 14:10, Matěj Cepl wrote:
Dne 06. 01. 22 v 12:21 Michael Ströder napsal(a):
Nobody is willing to pay for increasing backporting efforts needed for keeping outdated stuff. It's just that these costs are not really made transparent.
Sancta simplicitas! Who do you think actually pays real money to SUSE for maintaining SLE? Users of free Leap? Exactly the companies who complain that we upgrade too much.
Re-read my postings. Actually you're oversimplifying. Ciao, Michael.
On 2022-01-06 16:02, Michael Ströder wrote:
On 1/6/22 14:10, Matěj Cepl wrote:
Dne 06. 01. 22 v 12:21 Michael Ströder napsal(a):
Nobody is willing to pay for increasing backporting efforts needed for keeping outdated stuff. It's just that these costs are not really made transparent.
Sancta simplicitas! Who do you think actually pays real money to SUSE for maintaining SLE? Users of free Leap? Exactly the companies who complain that we upgrade too much.
Re-read my postings.
Actually you're oversimplifying.
Ciao, Michael.
And you are oversimplifying also The reality is simple SUSE is paid by its customers to stay in Python 3.6 SUSE will continue to maintain Python 3.6 as long as SUSE's customers pay them for that. This of course is an expense for SUSE so it's not something SUSE chooses lightly. Leap will have Python 3.6 as its default as long as the above stays true While the wishes of the community matter, SUSE is a money-making company in the business of making money, so SLE/Leap will 'follow the money' just as much as it follows the community, leading to situations like this. Better to accept it rather than demand SUSE throw away an opportunity to make good money vs..well what exactly do you offer SUSE in return? Your happiness?
On 1/10/22 14:45, rbrown wrote:
On 2022-01-06 16:02, Michael Ströder wrote:
On 1/6/22 14:10, Matěj Cepl wrote:
Dne 06. 01. 22 v 12:21 Michael Ströder napsal(a):
Nobody is willing to pay for increasing backporting efforts needed for keeping outdated stuff. It's just that these costs are not really made transparent.
Sancta simplicitas! Who do you think actually pays real money to SUSE for maintaining SLE? Users of free Leap? Exactly the companies who complain that we upgrade too much.
Re-read my postings.
Actually you're oversimplifying.
And you are oversimplifying also
Nope.
The reality is simple SUSE is paid by its customers to stay in Python 3.6
The above simple statement can only be false. And you know that very well. SLE customers are paying for some sort of "stable" support. What they consider "stable" in various project situations is not as clear as you state here. It varies a lot. Most times customers do not care about specific package versions of something until project requirements are in conflict with what's provided by the OS. So the big question is how to keep average amount of these conflicts low - and where the budget comes from. Obviously nobody has any one-size-fits-it-all solution.
While the wishes of the community matter, SUSE is a money-making company in the business of making money, so SLE/Leap will 'follow the money' I fully understand this. Being self-employed I also have to follow the money.
Please note that personally I'm not interested in Leap at all. Maybe I should have rather used "SLE15SP4" instead of "Leap 15.4" in the subject. Because SLE is what will affect my own customer projects.
well what exactly do you offer SUSE in return?
Happy SLE customers who do not consider migrating to another OS. The challenge in product management is that decisions are sometimes self-fulfilling prophecy. E.g. you limit a product in a certain way and then you can claim that the rest of the customers still willing to pay for that product are the nearly 100% who want to be it exactly that way. You will not know about the other customers and their needs. Maybe a solution would be to market OBS and openQA even more to make customers familiar with these powerful tools, very helpful to reach "stable" production even when doing more regular OS upgrades. Actually I'm trying this but my customers are rather scared by the amount of work. Well, maintaining infrastructure is always short on budget. :-/ Ciao, Michael.
On 2022-01-10 15:55, Michael Ströder wrote:
On 1/10/22 14:45, rbrown wrote:
On 2022-01-06 16:02, Michael Ströder wrote:
On 1/6/22 14:10, Matěj Cepl wrote:
Dne 06. 01. 22 v 12:21 Michael Ströder napsal(a):
Nobody is willing to pay for increasing backporting efforts needed for keeping outdated stuff. It's just that these costs are not really made transparent.
Sancta simplicitas! Who do you think actually pays real money to SUSE for maintaining SLE? Users of free Leap? Exactly the companies who complain that we upgrade too much.
Re-read my postings.
Actually you're oversimplifying.
And you are oversimplifying also
Nope.
The reality is simple SUSE is paid by its customers to stay in Python 3.6
The above simple statement can only be false. And you know that very well.
SLE customers are paying for some sort of "stable" support. What they consider "stable" in various project situations is not as clear as you state here. It varies a lot.
Most times customers do not care about specific package versions of something until project requirements are in conflict with what's provided by the OS. So the big question is how to keep average amount of these conflicts low - and where the budget comes from.
Obviously nobody has any one-size-fits-it-all solution.
The above statement is true, because, as I explained - SUSE supporting Python 3.6 beyond it's upstream EOL _costs_ SUSE a significant amount of money SUSE will be maintaining Python 3.6 with security patches despite the end of upstream support. This is expensive for SUSE. SUSE only spends money like that when the spending of that money is likely/certain to bring them MORE money than it's costing them. Therefore, any external observer can easily deduce that, because Python 3.6 is still being supported by SUSE, AND it's expensive for SUSE to support it, that SUSE has customers paying SUSE _specifically_ to continue supporting Python 3.6. If you were right, and my statements were not true, then SUSE would NOT support Python 3.6 and instead support something _cheaper_ for SUSE to support.
While the wishes of the community matter, SUSE is a money-making company in the business of making money, so SLE/Leap will 'follow the money' I fully understand this. Being self-employed I also have to follow the money.
Please note that personally I'm not interested in Leap at all. Maybe I should have rather used "SLE15SP4" instead of "Leap 15.4" in the subject. Because SLE is what will affect my own customer projects.
well what exactly do you offer SUSE in return?
Happy SLE customers who do not consider migrating to another OS.
Then have your SLE customers use the _correct_ customer channels to speak to their SUSE representatives and get their opinions fed to SUSE Product Management. This is not a mailinglist for SLE customers (or their advocates) to discuss the development of SLE distribution.
The challenge in product management is that decisions are sometimes self-fulfilling prophecy. E.g. you limit a product in a certain way and then you can claim that the rest of the customers still willing to pay for that product are the nearly 100% who want to be it exactly that way. You will not know about the other customers and their needs.
Sure, Product Management is the art of choosing which customers you want your product to appeal to. SUSE chose. So why are you bellyaching on an openSUSE mailinglist that SUSE should have chosen different? What do you expect the most positive outcome of this complain-thread could possibly be?
On 1/10/22 16:05, rbrown wrote:
So why are you bellyaching on an openSUSE mailinglist that SUSE should have chosen different?
What do you expect the most positive outcome of this complain-thread could possibly be?
So what positive outcome do you expect of your attitude? Ciao, Michael.
On 2022-01-10 17:34, Michael Ströder wrote:
On 1/10/22 16:05, rbrown wrote:
So why are you bellyaching on an openSUSE mailinglist that SUSE should have chosen different?
What do you expect the most positive outcome of this complain-thread could possibly be?
So what positive outcome do you expect of your attitude?
Ideally? Either more useful posts, or less posts, from yourself on this mailinglist.
On Thu, 2022-01-06 at 10:56 +0100, Matěj Cepl wrote:
Dne 05. 01. 22 v 21:18 Jan Engelhardt napsal(a):
So, from the point of view of an ISV, one has to rebuild all the Python packages which the distro originally shipped and which a software needs, just to take advantage of the 3.10 interpreter… right?
See how carefully I phrased my original sentence not to promise anything I cannot stand behind. We are currently brainstorming what to do next, but there is no solution yet. Whatever we see so far seems quite expensive in terms of manhours needed. Maintaining two stacks of Python packages so distant from each other as Python 3.6 and 3.10 gets really complicated really quickly.
Can't we identify those packages that _must_ be maintained for 3.6 (because they're required for core distro functionality) and maintain only those for both versions, replacing all others with the 3.10 packages? Martin
Martin Wilck <mwilck@suse.com> writes:
On Thu, 2022-01-06 at 10:56 +0100, Matěj Cepl wrote:
Dne 05. 01. 22 v 21:18 Jan Engelhardt napsal(a):
So, from the point of view of an ISV, one has to rebuild all the Python packages which the distro originally shipped and which a software needs, just to take advantage of the 3.10 interpreter… right?
See how carefully I phrased my original sentence not to promise anything I cannot stand behind. We are currently brainstorming what to do next, but there is no solution yet. Whatever we see so far seems quite expensive in terms of manhours needed. Maintaining two stacks of Python packages so distant from each other as Python 3.6 and 3.10 gets really complicated really quickly.
Can't we identify those packages that _must_ be maintained for 3.6 (because they're required for core distro functionality) and maintain only those for both versions, replacing all others with the 3.10 packages?
That ship has sailed for SLE 15: we are more or less guaranteeing our customer's that their SLE 15 GA system will not receive any disrupting (i.e. major version jump) updates and python packages suddenly changing their interpreter version from 3.6 to 3.10 will definitely count as that. Also, I think such a hybrid setup would just result in a huge mess. At that point I'd rather say that we should resort to just shipping Python, pip, wheel & development libraries for all the Python versions that we wish to support. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev
On Thursday 2022-01-06 12:40, Dan Čermák wrote:
That ship has sailed for SLE 15: we are more or less guaranteeing our customer's that their SLE 15 GA system will not receive any disrupting (i.e. major version jump) updates [...] Also, I think such a hybrid setup would just result in a huge mess.
*That* ship has sailed; by the looks of it, gcc11 is making its way into SLE15 and even SLE12. Not as default, but no one asked for that anyway.
and python packages suddenly changing their interpreter version from 3.6 to 3.10
Surely you can master update-alternatives priority such that 3.6 gets the higher ground? But that's also not really needed. I could easily live with #!/usr/bin/python3.10 in (my) programs, it's really just the python-blablamodules.
Am 06.01.22 um 13:02 schrieb Jan Engelhardt:
and python packages suddenly changing their interpreter version from 3.6 to 3.10 Surely you can master update-alternatives priority such that 3.6 gets the higher ground? But that's also not really needed.
/usr/bin/python3 is linked to /usr/bin/python3.6 without any update-alternatives involved. I think it is established by now, that python3.6 needs to remain the "primary" intepreter on Leap/SLE 15.
I could easily live with #!/usr/bin/python3.10 in (my) programs, it's really just the python-blablamodules.
So you are asking for multiflavor support with python310 enabled (but not primary). Which is, as far as I understand it. not on the table for 15.4. For a start, one could activate a python310 flavor in devel:languages:python:backports. (Which is actually currently broken due to other reasons). Then you get all the up to date python packages from Factory for your programs, unless they are hardcoded to python3. I don't know if that is "official" enough for you and your customers. - Ben
On Thu, 2022-01-06 at 12:40 +0100, Dan Čermák wrote:
Can't we identify those packages that _must_ be maintained for 3.6 (because they're required for core distro functionality) and maintain only those for both versions, replacing all others with the 3.10 packages?
That ship has sailed for SLE 15: we are more or less guaranteeing our customer's that their SLE 15 GA system will not receive any disrupting (i.e. major version jump) updates and python packages suddenly changing their interpreter version from 3.6 to 3.10 will definitely count as that. Also, I think such a hybrid setup would just result in a huge mess. At that point I'd rather say that we should resort to just shipping Python, pip, wheel & development libraries for all the Python versions that we wish to support.
I'm very much against that. It means we essentially give up packaging python modules. It also means we give up the maintenance and quality promises we used to provide for these packages. We give up a lot of the addon value that the distro used to provide, except for the most conservative fraction of users. The marketing message is: SUSE acknowledges that there's no benefit in distribution packaging of python modules, and that the upstream community does a better maintenance job than we do. This could easily be generalized to other programming environments. IMO pip and virtualenv are only for (some) developers and those who really want to be on the cutting edge. I've always tried to avoid it. The world isn't divided between extremely conservative customers and the cutting edge. IMO there's a lot of value in being able to use official, distribution-supported python 3.10 modules. Just my €0.02 of course, as I'm not a paying customer. Martin
Am 06.01.22 um 13:07 schrieb Martin Wilck:
At that point I'd rather say that we should resort to just shipping Python, pip, wheel & development libraries for all the Python versions that we wish to support. I'm very much against that. It means we essentially give up packaging
On Thu, 2022-01-06 at 12:40 +0100, Dan Čermák wrote: python modules.
Plus, it is just not possible. Every rpm package needs its dependencies in the system repositories. You can't tell it "get the rest online from PyPI, I don't care if it is safe". - Ben
Relevant, just found on planet.kernel.org: https://zaitcev.livejournal.com/263602.html :-) On 1/6/22 14:56, Ben Greiner wrote:
Am 06.01.22 um 13:07 schrieb Martin Wilck:
At that point I'd rather say that we should resort to just shipping Python, pip, wheel & development libraries for all the Python versions that we wish to support. I'm very much against that. It means we essentially give up packaging
On Thu, 2022-01-06 at 12:40 +0100, Dan Čermák wrote: python modules.
Plus, it is just not possible. Every rpm package needs its dependencies in the system repositories. You can't tell it "get the rest online from PyPI, I don't care if it is safe".
- Ben
On 1/7/22 08:38, Georg Pfuetzenreuter wrote:
On 1/6/22 14:56, Ben Greiner wrote:
Am 06.01.22 um 13:07 schrieb Martin Wilck:
At that point I'd rather say that we should resort to just shipping Python, pip, wheel & development libraries for all the Python versions that we wish to support. I'm very much against that. It means we essentially give up packaging
On Thu, 2022-01-06 at 12:40 +0100, Dan Čermák wrote: python modules.
Plus, it is just not possible. Every rpm package needs its dependencies in the system repositories. You can't tell it "get the rest online from PyPI, I don't care if it is safe".
Relevant, just found on planet.kernel.org: https://zaitcev.livejournal.com/263602.html Yes, delivery chain attacks are indeed a notorously underestimated risk.
But do you really think openSUSE/SLE or any other Linux distro is independent from PyPI? Just have a look at the Source: lines in Python packages. And no, replacing those lines with github URLs or similar does not help either. And IMO none of the Linux distros have really strong security controls in place to avoid more advanced delivery chain attacks. If distro maintainers claim something else they're naive or vain or both. And don't get me started commenting the security of widespread CI/CD, DevOps operational practices out there. Ciao, Michael.
Am 09.01.22 um 13:39 schrieb Michael Ströder:
On 1/7/22 08:38, Georg Pfuetzenreuter wrote:
On 1/6/22 14:56, Ben Greiner wrote:
Am 06.01.22 um 13:07 schrieb Martin Wilck:
At that point I'd rather say that we should resort to just shipping Python, pip, wheel & development libraries for all the Python versions that we wish to support. I'm very much against that. It means we essentially give up packaging
On Thu, 2022-01-06 at 12:40 +0100, Dan Čermák wrote: python modules.
Plus, it is just not possible. Every rpm package needs its dependencies in the system repositories. You can't tell it "get the rest online from PyPI, I don't care if it is safe".
Relevant, just found on planet.kernel.org: https://zaitcev.livejournal.com/263602.html Yes, delivery chain attacks are indeed a notorously underestimated risk.
But do you really think openSUSE/SLE or any other Linux distro is independent from PyPI? Just have a look at the Source: lines in Python packages. And no, replacing those lines with github URLs or similar does not help either.
At least obs checks those lines at commit time and breaks if the source changes. This is significantly different than having pip (or npm or php composer for that matter) pull in a random package it finds at install time. The blog post claims that the PyPI package for nose was "unofficial". Of course it is the packagers duty to make sure that only sane and official sources are included into the rpmbuild. - Ben
Am 09.01.22 um 13:39 schrieb Michael Ströder:
On 1/7/22 08:38, Georg Pfuetzenreuter wrote:
On 1/6/22 14:56, Ben Greiner wrote:
Am 06.01.22 um 13:07 schrieb Martin Wilck:
> At that point I'd rather say that we should resort to just > shipping Python, pip, wheel & development libraries for all the > Python > versions that we wish to support. I'm very much against that. It means we essentially give up packaging
On Thu, 2022-01-06 at 12:40 +0100, Dan Čermák wrote: python modules.
Plus, it is just not possible. Every rpm package needs its dependencies in the system repositories. You can't tell it "get the rest online from PyPI, I don't care if it is safe".
Relevant, just found on planet.kernel.org: https://zaitcev.livejournal.com/263602.html Yes, delivery chain attacks are indeed a notorously underestimated risk.
But do you really think openSUSE/SLE or any other Linux distro is independent from PyPI? Just have a look at the Source: lines in Python packages. And no, replacing those lines with github URLs or similar does not help either.
At least obs checks those lines at commit time and breaks if the source changes. This is significantly different than having pip (or npm or php composer for that matter) pull in a random package it finds at install time. And how does this help if an attacker managed to publish a manipulated
The blog post claims that the PyPI package for nose was "unofficial". Of course it is the packagers duty to make sure that only sane and official sources are included into the rpmbuild. And how should a packager really verify this? Given the lack of
On 1/9/22 14:00, Ben Greiner wrote: source distribution on PyPI? Or even worse the attacker managed to commit and release code on the code forge used, which also happened in the recent past? packagers reviewing each code line in each change is illusionary. Yes, you can do some plausibility tests. And in this particular example the module package "nose" was known to be dead and unmaintained, a strong indication that it should be hunked out from your delivery chain. But there are many packages in openSUSE where upstream project could be considered dead. Well, openSUSE still ships it and python-nose.spec contains PyPI URLs... Ciao, Michael.
Am 09.01.22 um 14:15 schrieb Michael Ströder:
Am 09.01.22 um 13:39 schrieb Michael Ströder:
On 1/7/22 08:38, Georg Pfuetzenreuter wrote:
On 1/6/22 14:56, Ben Greiner wrote:
Am 06.01.22 um 13:07 schrieb Martin Wilck:
On Thu, 2022-01-06 at 12:40 +0100, Dan Čermák wrote: >> At that point I'd rather say that we should resort to just >> shipping Python, pip, wheel & development libraries for all the >> Python >> versions that we wish to support. I'm very much against that. It means we essentially give up packaging python modules.
Plus, it is just not possible. Every rpm package needs its dependencies in the system repositories. You can't tell it "get the rest online from PyPI, I don't care if it is safe".
Relevant, just found on planet.kernel.org: https://zaitcev.livejournal.com/263602.html Yes, delivery chain attacks are indeed a notorously underestimated risk.
But do you really think openSUSE/SLE or any other Linux distro is independent from PyPI? Just have a look at the Source: lines in Python packages. And no, replacing those lines with github URLs or similar does not help either.
At least obs checks those lines at commit time and breaks if the source changes. This is significantly different than having pip (or npm or php composer for that matter) pull in a random package it finds at install time. And how does this help if an attacker managed to publish a manipulated
On 1/9/22 14:00, Ben Greiner wrote: source distribution on PyPI? Or even worse the attacker managed to commit and release code on the code forge used, which also happened in the recent past?
It does not help. But you are moving the goal posts.
The blog post claims that the PyPI package for nose was "unofficial". Of course it is the packagers duty to make sure that only sane and official sources are included into the rpmbuild. And how should a packager really verify this? Given the lack of packagers reviewing each code line in each change is illusionary.
Yes, you can do some plausibility tests.
A link from the Github page or official website to the pypi page is a start.
And in this particular example the module package "nose" was known to be dead and unmaintained, a strong indication that it should be hunked out from your delivery chain. But there are many packages in openSUSE where upstream project could be considered dead.
Well, openSUSE still ships it and python-nose.spec contains PyPI URLs...
In fact, Matej has been working hard on eliminating nose from depending packages, even to the point of annoying upstream projects about it. We are down to 8 packages right now (unless the python36 drop and python310 addition masks some packages because they are unresolvable). Ipython is dropping it very soon in v8.0 [1] [ben@skylab:~]% osc whatdependson openSUSE:Factory python-nose standard x86_64 python-nose : anki python-boto python-hdf5storage python-ipykernel python-ipyparallel python-ipython:test python-pprintpp python-pysmb I cannot reproduce what Pete Zaitcev is talking about in his blog post regarding nose. Maybe it has been corrected at the PyPI side in the meantime. - The PyPI page lists the source maintainers, not sure why he needed to fuzzy-investigate in git logs. - https://nose.readthedocs.io/en/latest/ links to http://pypi.python.org/pypi/nose/1.3.7 - https://files.pythonhosted.org/packages/58/a5/0dc93c3ec33f4e281849523a5a913f... released on Jun2, 2015 is identical to https://codeload.github.com/nose-devs/nose/tar.gz/refs/tags/release_1.3.7 except for the test content and some development files. Again, a manipulation of nose-1.3.7.tar.gz at PyPI after the rpm package has been plausability checked and commited does not affect the rpm package. It does affect a pip install, however.
Ciao, Michael.
On Sunday 2022-01-09 13:39, Michael Ströder wrote:
Relevant, just found on planet.kernel.org: https://zaitcev.livejournal.com/263602.html
[..] replacing those lines with github URLs or similar does not help either.
It does help in one aspect. (Zaitcev) """it is not possible to contact listed maintainers of N in PyPI, and there is no way to report the problem: the problem tracking system of PyPI is all plastered with warnings not to use it for problems with packages""" So if N is on Github/Someforge instead, one can try to contact the Github user via email in the git log (if meaningful address present), or via an issue (if so enabled on Github), or by abusing a pull request as an issue (I have not seen a knob to turn PRs off yet).
Am 09.01.22 um 16:17 schrieb Jan Engelhardt:
On Sunday 2022-01-09 13:39, Michael Ströder wrote:
Relevant, just found on planet.kernel.org: https://zaitcev.livejournal.com/263602.html [..] replacing those lines with github URLs or similar does not help either. It does help in one aspect.
(Zaitcev) """it is not possible to contact listed maintainers of N in PyPI, and there is no way to report the problem: the problem tracking system of PyPI is all plastered with warnings not to use it for problems with packages"""
So if N is on Github/Someforge instead, one can try to contact the Github user via email in the git log (if meaningful address present), or via an issue (if so enabled on Github), or by abusing a pull request as an issue (I have not seen a knob to turn PRs off yet).
That is unrelated to the `Source:` tags. There should always be an URL: Tag pointing to upstream's online presence.
i have two systems left to migrate to tumbleweed... Am 03.01.2022 um 09:52 schrieb Michael Ströder:
HI!
Python 3.6 has reached EOL and various Python module packages already drop support for 3.6. But still Python 3.6 is planned to be shipped with Leap 15.4 instead of a newer version.
IMO this does not make sense at all.
Ciao, Michael.
-- Mathias Homann Mathias.Homann@openSUSE.org Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
Am Montag, 3. Januar 2022, 12:10:17 CET schrieb Michael Ströder:
On 1/3/22 11:02, Mathias Homann wrote:
i have two systems left to migrate to tumbleweed...
My personal systems are *all* running Tumbleweed. That's not the point.
It actually is, kinda. In my case opensuse "never change a running system" a.k.a. leap turned out to not support recent hardware (as in, couldn't get X11 on my laptop to work, and some other things like that), which is why I used TW on it - and shortly after that upgraded my desktop and (so far) one of the three servers to TW. Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy@tuxonline.tech Matrix: @mathias:eregion.de IRC: [Lemmy] on liberachat and ircnet (bouncer active) keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
On 1/3/22 19:22, Michael Ströder wrote:
HI!
Python 3.6 has reached EOL and various Python module packages already drop support for 3.6. But still Python 3.6 is planned to be shipped with Leap 15.4 instead of a newer version.
Instead of should read as "As well as"
IMO this does not make sense at all.
This is what SUSE's customers want so SUSE pays people to maintain certain versions of python even after upstream doesn't. Its also why they paid people to develop "Single Spec" to make it easier to maintain multiple versions of python packages in Leap. -- 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
Am 03.01.22 um 11:22 schrieb Simon Lees:
On 1/3/22 19:22, Michael Ströder wrote:
HI!
Python 3.6 has reached EOL and various Python module packages already drop support for 3.6. (...)
(...) Its also why they paid people to develop "Single Spec" to make it easier to maintain multiple versions of python packages in Leap.
A note of caution: The singlespec approach only works when a package supports all target flavors. Lots of upstream packages only introduced compatibility with Python 3.9 or Python 3.10 after they dropped Python 3.6 support. So when you plan to enable a python39 or python310 flavor in 15.4, and that is how I read your statement, you will still require a paid SUSE engineer to either maintain two different package versions or that lots of suse-specific patches need to be introduced. With the Factory first approach, these patches would also appear in Tumbleweed, making the life harder for everyone. - Ben
On Mon, Jan 3, 2022 at 11:42 AM Ben Greiner <code@bnavigator.de> wrote:
Am 03.01.22 um 11:22 schrieb Simon Lees:
On 1/3/22 19:22, Michael Ströder wrote:
HI!
Python 3.6 has reached EOL and various Python module packages already drop support for 3.6. (...)
(...) Its also why they paid people to develop "Single Spec" to make it easier to maintain multiple versions of python packages in Leap.
A note of caution: The singlespec approach only works when a package supports all target flavors. Lots of upstream packages only introduced compatibility with Python 3.9 or Python 3.10 after they dropped Python 3.6 support. So when you plan to enable a python39 or python310 flavor in 15.4, and that is how I read your statement, you will still require a paid SUSE engineer to either maintain two different package versions or that lots of suse-specific patches need to be introduced. With the Factory first approach, these patches would also appear in Tumbleweed, making the life harder for everyone.
Like 1.x versions of Tensorflow that I am required to support. That's a tricky one to find support for in newer Python versions. I so wish I could stop using that... -- Roger Oberholtzer
On 1/3/22 21:11, Ben Greiner wrote:
Am 03.01.22 um 11:22 schrieb Simon Lees:
On 1/3/22 19:22, Michael Ströder wrote:
HI!
Python 3.6 has reached EOL and various Python module packages already drop support for 3.6. (...)
(...) Its also why they paid people to develop "Single Spec" to make it easier to maintain multiple versions of python packages in Leap.
A note of caution: The singlespec approach only works when a package supports all target flavors. Lots of upstream packages only introduced compatibility with Python 3.9 or Python 3.10 after they dropped Python 3.6 support. So when you plan to enable a python39 or python310 flavor in 15.4, and that is how I read your statement, you will still require a paid SUSE engineer to either maintain two different package versions or that lots of suse-specific patches need to be introduced. With the Factory first approach, these patches would also appear in Tumbleweed, making the life harder for everyone.
That's not quite how the factory first approach works, factory first is about making sure that bugfixes and features that go into SLE releases also go into tumbleweed so that they make it into the next major SLE release. Given that python 3.6 will soon be dropped from tumbleweed and won't be in SLE-16 patches related to keeping python 3.6 don't need to go into factory, in the same way sometimes in SLE / Leap we use a patch to fix an issue rather then taking a newer version and we don't send that patch to factory if we take the newer version there. What matters in factory first is the issue is resolved in both SLE and Factory so in this case it shouldn't affect tumbleweed, and yes if customers need the package for both then we will work on it because that is why they pay us. -- 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/3/22 11:41, Ben Greiner wrote:
Am 03.01.22 um 11:22 schrieb Simon Lees:
On 1/3/22 19:22, Michael Ströder wrote:
Python 3.6 has reached EOL and various Python module packages already drop support for 3.6. (...)
(...) Its also why they paid people to develop "Single Spec" to make it easier to maintain multiple versions of python packages in Leap.
A note of caution: The singlespec approach only works when a package supports all target flavors. Lots of upstream packages only introduced compatibility with Python 3.9 or Python 3.10 after they dropped Python 3.6 support. So when you plan to enable a python39 or python310 flavor in 15.4, and that is how I read your statement, you will still require a paid SUSE engineer to either maintain two different package versions or that lots of suse-specific patches need to be introduced. With the Factory first approach, these patches would also appear in Tumbleweed, making the life harder for everyone.
That's exactly one of the bigger problems! Ciao, Michael.
On 1/3/22 11:22, Simon Lees wrote:
On 1/3/22 19:22, Michael Ströder wrote:
Python 3.6 has reached EOL and various Python module packages already drop support for 3.6. But still Python 3.6 is planned to be shipped with Leap 15.4 instead of a newer version.
Instead of should read as "As well as"
IMO this does not make sense at all.
This is what SUSE's customers want so SUSE pays people to maintain certain versions of python even after upstream doesn't. Its also why they paid people to develop "Single Spec" to make it easier to maintain multiple versions of python packages in Leap.
In know this theoretical argument quite well. But I'm really tired of it. Outdated is not "stable". I have some customers running SLE and in practice 3rd-party Python packages are not well-maintained and are too old for installing recent software. So in real life this causes all sorts of additional efforts, even with really bad work-arounds. IMO it's a bad product management decision. Ciao, Michael.
On 1/3/22 21:47, Michael Ströder wrote:
On 1/3/22 11:22, Simon Lees wrote:
On 1/3/22 19:22, Michael Ströder wrote:
Python 3.6 has reached EOL and various Python module packages already drop support for 3.6. But still Python 3.6 is planned to be shipped with Leap 15.4 instead of a newer version.
Instead of should read as "As well as"
IMO this does not make sense at all.
This is what SUSE's customers want so SUSE pays people to maintain certain versions of python even after upstream doesn't. Its also why they paid people to develop "Single Spec" to make it easier to maintain multiple versions of python packages in Leap.
In know this theoretical argument quite well. But I'm really tired of it.
Outdated is not "stable".
I have some customers running SLE and in practice 3rd-party Python packages are not well-maintained and are too old for installing recent software. So in real life this causes all sorts of additional efforts, even with really bad work-arounds. IMO it's a bad product management decision.
I am not a product manager so I don't get to make such decisions and can't really speak on behalf of them, but what I can say is the general use case that is put to us is we have customers who for example buy a new piece of hardware, provision it with the services they require and then expect not to need to touch that system again for the 5 year lifetime of the hardware other then for security updates. Then in 5 years when the hardware is end of life before decommissioning it they will set up new hardware with an updated software stack and use that for the next 5 years. This is one of the main usecases SLE has to support and unfortunately because openSUSE on its own doesn't have the man power to do something else it chooses to inherit SLE for Leap and therefore Leap has to be able to live with similar constraints. -- 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/3/22 12:57, Simon Lees wrote:
I am not a product manager so I don't get to make such decisions and can't really speak on behalf of them, but what I can say is the general use case that is put to us is we have customers who for example buy a new piece of hardware, provision it with the services they require and then expect not to need to touch that system again for the 5 year lifetime of the hardware other then for security updates. [..] This is one of the main usecases SLE has to support [..]
Most of my customers do not run SLE or other Linux distros on bare-metal anymore. Decisions SUSE takes now will take a while until next SLE15SP4 release and will take another 2-3 years before customers pickup this release in their deployment. Until then everything's horribly outdated. In practice this leads to custom build processes and really weird manual update processes. :-( Ciao, Michael.
On 03/01/2022 09:52, Michael Ströder wrote:
HI!
Python 3.6 has reached EOL and various Python module packages already drop support for 3.6. But still Python 3.6 is planned to be shipped with Leap 15.4 instead of a newer version.
IMO this does not make sense at all.
Ciao, Michael. If I understand correctly, OpenSuse Leap is defacto (becoming) the consumer version of the Suse SLE. The latter is offered to companies willing to run software which is already outdated in it's inception and will stay that way - expect for security updates - until a "new" SLE version is distributed. After which the cycle repeats itself. That notion is missing on the OpenSuse Leap pages, since it only talks about Leap being a stable version.
In the rare instances that Tumbleweed is failing, I used to have Leap as backup but recently went to another rolling distribution because the software there was so old that it became unusable to function any longer as a backup. That said, it might be an idea that OpenSuse is rethinking it's strategy. For example, forgo the whole Leap series, which will free resources to concentrate on Tumbleweed. Also, as a suggestion, once a year repackage Tumbleweed of a few months old into a rebranded "stable" version and provide only security updates. IMO, if you do not have enough resources to provided for a reasonable up-to-date consumer product, then don´t cling to Leap just to be able to offer a consumer product tagged as "stable" and thereby offering packages who are EOL, outdated or even called ancient. Think what image damage the OpenSuse brand might run into in this ever faster evolving landscape. Also, this is not the first nor - I expect - the last rally about Leap following SLE. --- Frans.
On 1/6/22 23:55, Frans de Boer wrote:
On 03/01/2022 09:52, Michael Ströder wrote:
HI!
Python 3.6 has reached EOL and various Python module packages already drop support for 3.6. But still Python 3.6 is planned to be shipped with Leap 15.4 instead of a newer version.
IMO this does not make sense at all.
Ciao, Michael. If I understand correctly, OpenSuse Leap is defacto (becoming) the consumer version of the Suse SLE. The latter is offered to companies willing to run software which is already outdated in it's inception and will stay that way - expect for security updates - until a "new" SLE version is distributed. After which the cycle repeats itself. That notion is missing on the OpenSuse Leap pages, since it only talks about Leap being a stable version.
In the rare instances that Tumbleweed is failing, I used to have Leap as backup but recently went to another rolling distribution because the software there was so old that it became unusable to function any longer as a backup. That said, it might be an idea that OpenSuse is rethinking it's strategy. For example, forgo the whole Leap series, which will free resources to concentrate on Tumbleweed. Also, as a suggestion, once a year repackage Tumbleweed of a few months old into a rebranded "stable" version and provide only security updates.
Given that Leap takes the core of its operating system directly from SLE it actually takes a surprisingly small amount of effort to keep going, to the point where I doubt that dropping it would result in tumbleweed being significantly better. A significant amount of work on tumbleweed is already done by SUSE employees who also maintain those packages for SLE. In fact SUSE has policies designed to ensure its employees do such. On the other hand the amount of effort to put out security updates for something new every year would be incredibly high in comparason. A significantly large number of the security updates for leap especially for security sensitive packages come directly from SLE. If we could find the resources to do this I agree it would be a great distro and probably more useful for many people then Leap and Tumbleweed. But to do this we'd need to probably find additional maintainers for most of the core packages, tumbleweed and obviously SLE are both very important to SUSE which is why they pay people such as myself to maintain packages in both. A yearly distro would be much less interesting to SUSE so they would probably be less likely to give the same support as they do to the other distros. Having said that the infrastructure is largely there so if a group of people who are passionate about this wanted to set it up it would be more then possible but as with practically everything in open source software it takes a group of people that are both passionate about it and are willing to put the time and effort in to make it happen. -- 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/7/22 07:46, Simon Lees wrote:
Having said that the infrastructure is largely there so if a group of people who are passionate about this wanted to set it up it would be more then possible but as with practically everything in open source software it takes a group of people that are both passionate about it and are willing to put the time and effort in to make it happen.
And, too, as with everything in open source software, people have different opinions of what a project stands for and what its product should be about. I, personally, like Leap as it is - the other big enterprise GNU/Linux vendor (yes, the one with the red hat) ditched the free fork of their enterprise distribution - SUSE and the openSUSE project keep Leap, a free SLE fork, (whether that's the right definition or not) alive - and I value that a lot. I would even go as far as to say that there is no real alternative to the current, enterprise grade, Leap - other distributions are either rolling, not backed by a commercial enterprise product, or do not offer an open source community. I understand that other users do not like being presented with outdated packages and legacy code - I understand people want a "different" Leap - but for me, coming from an enterprise background, Leap gives security and stability for the server-side open source projects I run and experiment with. Best Georg
On 07/01/2022 09.20, Georg Pfuetzenreuter wrote:
On 1/7/22 07:46, Simon Lees wrote:
Having said that the infrastructure is largely there so if a group of people who are passionate about this wanted to set it up it would be more then possible but as with practically everything in open source software it takes a group of people that are both passionate about it and are willing to put the time and effort in to make it happen.
And, too, as with everything in open source software, people have different opinions of what a project stands for and what its product should be about. I, personally, like Leap as it is - the other big enterprise GNU/Linux vendor (yes, the one with the red hat) ditched the free fork of their enterprise distribution - SUSE and the openSUSE project keep Leap, a free SLE fork, (whether that's the right definition or not) alive - and I value that a lot. I would even go as far as to say that there is no real alternative to the current, enterprise grade, Leap - other distributions are either rolling, not backed by a commercial enterprise product, or do not offer an open source community.
I understand that other users do not like being presented with outdated packages and legacy code - I understand people want a "different" Leap - but for me, coming from an enterprise background, Leap gives security and stability for the server-side open source projects I run and experiment with.
I think it is simply time to ship SLE 16. Keep 15 with security updates only for paying customers that want it. I like Leap, but this keeping of old packages is going too far. Four years, really? Are SLE customers installing new machines really liking 15, or having trouble? -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Am 07.01.22 um 10:21 schrieb Carlos E. R.:
I like Leap, but this keeping of old packages is going too far. Four years, really?
Are SLE customers installing new machines really liking 15, or having trouble?
SLE customers installing new machines are using SLES12-SP5. My cow-orkers in operating are starting now with moving productive machines to SLES15. SLES15-SP1 of course, not SP3. If SUSE shipped a SLES16 now, they would be ready for adoption of it maybe in 2025. Especially as this would have major, breaking changes (like: usrmerge) that would need excessive testing. (Not really, but that would be their argument to keep the old stuff). This is most likely one of the bigger SUSE customers in europe, if not the biggest. And yes, I tell them daily to go away and kill themselves when they come around with on their SLES12 installations, that would be simply go away if they switched to SLES15+. Or when they whine about their sles15 problems that come from them using SP1 instead of SP3+updates. So yes, paying customers really like old stuff :-) I personally am happy with Leap $releasever as a server machine at home. My python stuff (mostly some statistics collection things on the server) work well enough with python 3.6 (I finally had to switch them over from py2 to py3 end of 2020 ;-) More complex, "modern" things (example: home-assistant) are basically not installable on any released OS that the developers are not using, so the way to go for complex things is to use a container or dedicated small VM with an appliance for the application. I do not think this is nice or good, but the way application development is done (many projects not caring for anything but their own appliance and the developer's own setup), this is just the only workable approach. And I really appreciate stuff in Leap not changing as often as in Tumbleweed. I run TW on my laptop, where it is no hassle to reboot every other day for a new kernel or glibc, and as everything on there is my personal use only, even if something breaks it is not a big problem getting it going again, or just to stop using it for some days until it is fixed. But on the server, I really like having to look at it only once per month or so. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On 07/01/2022 10.47, Stefan Seyfried wrote:
Am 07.01.22 um 10:21 schrieb Carlos E. R.:
I like Leap, but this keeping of old packages is going too far. Four years, really?
Are SLE customers installing new machines really liking 15, or having trouble?
SLE customers installing new machines are using SLES12-SP5.
My cow-orkers in operating are starting now with moving productive machines to SLES15.
SLES15-SP1 of course, not SP3.
If SUSE shipped a SLES16 now, they would be ready for adoption of it maybe in 2025. Especially as this would have major, breaking changes (like: usrmerge) that would need excessive testing. (Not really, but that would be their argument to keep the old stuff).
This is most likely one of the bigger SUSE customers in europe, if not the biggest.
And yes, I tell them daily to go away and kill themselves when they come around with on their SLES12 installations, that would be simply go away if they switched to SLES15+. Or when they whine about their sles15 problems that come from them using SP1 instead of SP3+updates.
So yes, paying customers really like old stuff :-)
Ok, that's about servers. What about desktop customers? There are people complaining that Leap doesn't run in their new laptops, doesn't this happen to paying customers?
I personally am happy with Leap $releasever as a server machine at home. My python stuff (mostly some statistics collection things on the server) work well enough with python 3.6 (I finally had to switch them over from py2 to py3 end of 2020 ;-) More complex, "modern" things (example: home-assistant) are basically not installable on any released OS that the developers are not using, so the way to go for complex things is to use a container or dedicated small VM with an appliance for the application. I do not think this is nice or good, but the way application development is done (many projects not caring for anything but their own appliance and the developer's own setup), this is just the only workable approach.
And I really appreciate stuff in Leap not changing as often as in Tumbleweed. I run TW on my laptop, where it is no hassle to reboot every other day for a new kernel or glibc, and as everything on there is my personal use only, even if something breaks it is not a big problem getting it going again, or just to stop using it for some days until it is fixed. But on the server, I really like having to look at it only once per month or so.
I also appreciate stuff in Leap not changing as often as in Tumbleweed, in my desktop machine, laptop, and miniserver. TW is a no-no for me. But Leap is getting way too old. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On Fri, 2022-01-07 at 11:00 +0100, Carlos E. R. wrote:
On 07/01/2022 10.47, Stefan Seyfried wrote:
So yes, paying customers really like old stuff :-)
Ok, that's about servers. What about desktop customers?
To some extent, they'll have to "bite the bullet" (I'm writing this on 6-months old laptop running Leap 15.3). This is what Leap is - an open derivate of an enterprise distibution. If you want the latest applications, flatpak, appimage or containers provide a wide range of possible approaches. I'm using flatpak a lot on Leap. (Yes, the integration of flatpak, appimage etc. could be smoother - ideally users wouldn't have to bother about configuring it at all).
There are people complaining that Leap doesn't run in their new laptops, doesn't this happen to paying customers?
There are various ways to make new hardware work with Leap. First of all, SUSE does a lot of driver backports for SLE, which will be available on Leap, too. Of course that's mostly for hardware that matters in the data center. Hardware vendors support SUSE with drivers and backports for server hardware, but not for home, desktop, or mobile devices. Thus storage and (wired) network devices should "just work" most of the time. For other devices, you can install the kernel from Kernel:stable or Kernel:stable:Backport, maintained by SUSE engineering, and enjoy every driver that upstream supports. And/or you can use add-on repos like "hardware" or "Printing" to get even more backports, KMPs, and user space drivers. (Maybe we should stop discouraging users from enabling these repos). Ideally, you get the best of worlds: A stable user space with support for recent hardware, timely delivery of security updates for the most crucial parts of the distro, and flatpak or similar for the cutting- edge stuff. That said, I would like us to push updates for user-space hardware "drivers" to SLE/Leap more aggressively. One example is the hplip printer/scanner driver suite, for which I am a maintainer. I see little or no reason to freeze hplip at old versions. The main reason for doing so is lack of QA resources, but hplip very rarely causes regressions, and even if does, they are hardly fatal. printd is another example, it's hopelessly outdated on Leap 15.3 but could be updated with minor risk (it will be in 15.4). There are lots of other examples.
I also appreciate stuff in Leap not changing as often as in Tumbleweed, in my desktop machine, laptop, and miniserver. TW is a no-no for me. But Leap is getting way too old.
Well, you've got to face the fact that Leap is like Ubuntu LTS, or even more enterprise-like. There simply is no product like non-LTS Ubuntu in the SUSE universe at this time. <rant> You should also take into account that a significant part of the problem is upstream. I used to be a python fanboy, but no more. I disliked how the py2->py3 transition was forced upon users, and dislike even more how backward compatibility is repeatedly busted in the 3.x series. If that didn't happen, this entire thread would be unnecessary. Yes, they announce these incompatibilities early. But still - they break stuff deliberately, and repeatedly. IMO python is not a good choice any more for mature projects with long maintenance cycles, unless the maintainers enjoy pointlessly "modernizing" their code every few months. </rant> Martin
On 07/01/2022 13.27, Martin Wilck wrote:
On Fri, 2022-01-07 at 11:00 +0100, Carlos E. R. wrote:
On 07/01/2022 10.47, Stefan Seyfried wrote:
So yes, paying customers really like old stuff :-)
Ok, that's about servers. What about desktop customers?
To some extent, they'll have to "bite the bullet" (I'm writing this on 6-months old laptop running Leap 15.3). This is what Leap is - an open derivate of an enterprise distibution. If you want the latest applications, flatpak, appimage or containers provide a wide range of possible approaches. I'm using flatpak a lot on Leap. (Yes, the integration of flatpak, appimage etc. could be smoother - ideally users wouldn't have to bother about configuring it at all).
... Oh, I agree with everything you said, rant part included. Still... -- -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
Dne 07. 01. 22 v 11:00 Carlos E. R. napsal(a):
So yes, paying customers really like old stuff :-)
Ok, that's about servers. What about desktop customers?
There are people complaining that Leap doesn't run in their new laptops, doesn't this happen to paying customers?
You mean that Year of Linux on the desktop? I am afraid it hasn’t happened yet. Yes, there are some paying Linux customers with desktop installations (when I was working at Red Hat it was in the desktop team, and Red Hat is not a charity so they don't support something they cannot get paid for), but overwhelming overwhelming majority of paying customers are on servers. And usually not those who have one or two servers in their office, but those who have fleet of hundreds of servers in their basements. And yes, we have mounting pressure from our customers to have continuation of support for Python 2.7 on SLE-12 (or even SLE-11, it is still supported for some special, read paying more, customers). Those people cannot care less about EOS of Python 3.6. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 <”}}}><
On 1/7/22 20:30, Carlos E. R. wrote:
On 07/01/2022 10.47, Stefan Seyfried wrote:
Am 07.01.22 um 10:21 schrieb Carlos E. R.:
I like Leap, but this keeping of old packages is going too far. Four years, really?
Are SLE customers installing new machines really liking 15, or having trouble?
SLE customers installing new machines are using SLES12-SP5.
My cow-orkers in operating are starting now with moving productive machines to SLES15.
SLES15-SP1 of course, not SP3.
If SUSE shipped a SLES16 now, they would be ready for adoption of it maybe in 2025. Especially as this would have major, breaking changes (like: usrmerge) that would need excessive testing. (Not really, but that would be their argument to keep the old stuff).
This is most likely one of the bigger SUSE customers in europe, if not the biggest.
And yes, I tell them daily to go away and kill themselves when they come around with on their SLES12 installations, that would be simply go away if they switched to SLES15+. Or when they whine about their sles15 problems that come from them using SP1 instead of SP3+updates.
So yes, paying customers really like old stuff :-)
Ok, that's about servers. What about desktop customers?
There are people complaining that Leap doesn't run in their new laptops, doesn't this happen to paying customers?
Yep but generally the kernel team is really good at backporting new hardware enablement, they just don't have access to all the hardware in the world so if you create a bug report there is a fair chance they will be able to backport the support. -- 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 Sat, 2022-01-08 at 11:32 +1030, Simon Lees wrote:
Yep but generally the kernel team is really good at backporting new hardware enablement, they just don't have access to all the hardware in the world so if you create a bug report there is a fair chance they will be able to backport the support.
Yes, but that applies only for "enterprise" hardware. Martin
On 1/10/22 19:04, Martin Wilck wrote:
On Sat, 2022-01-08 at 11:32 +1030, Simon Lees wrote:
Yep but generally the kernel team is really good at backporting new hardware enablement, they just don't have access to all the hardware in the world so if you create a bug report there is a fair chance they will be able to backport the support.
Yes, but that applies only for "enterprise" hardware.
My experience has been where there isn't significant effort involved they will do more then that, after all at the end of the day i'm pretty sure we don't have a whitelist of supported SLED hardware (someone correct me if i'm 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 Mon, 10 Jan 2022 09:34:06 +0100, Martin Wilck wrote:
On Sat, 2022-01-08 at 11:32 +1030, Simon Lees wrote:
Yep but generally the kernel team is really good at backporting new hardware enablement, they just don't have access to all the hardware in the world so if you create a bug report there is a fair chance they will be able to backport the support.
Yes, but that applies only for "enterprise" hardware.
No, we do take care of bug reports from openSUSE users, and we do backport things for non-enterprise hardware, too. The only caveat is that it's a "best effort"; we have to keep the full compatibility and can't take too much risk to break existing stuff. So, earlier reported, better chance to have a fix. Takashi
On Tue, 2022-01-11 at 16:08 +0100, Takashi Iwai wrote:
On Mon, 10 Jan 2022 09:34:06 +0100, Martin Wilck wrote:
On Sat, 2022-01-08 at 11:32 +1030, Simon Lees wrote:
Yep but generally the kernel team is really good at backporting new hardware enablement, they just don't have access to all the hardware in the world so if you create a bug report there is a fair chance they will be able to backport the support.
Yes, but that applies only for "enterprise" hardware.
No, we do take care of bug reports from openSUSE users, and we do backport things for non-enterprise hardware, too.
Ok. My statement was wrong, because I negated Simon's "fair chance", which certainly exists. Sorry about that. What I meant, but expressed wrongly, was rather that most of the time there are no guarantees when it comes to non-server hardware.
The only caveat is that it's a "best effort"; we have to keep the full compatibility and can't take too much risk to break existing stuff.
That's the point. For enterprise hardware we have feature requests from partners and paying customers, and dedicated resources. That goes further, and provides stronger guarantees, than the "best effort" support you mentioned. Martin
On Friday 2022-01-07 10:47, Stefan Seyfried wrote:
And yes, I tell them daily to go away and kill themselves when they come around with on their SLES12 installations, that would be simply go away if they switched to SLES15+. Or when they whine about their sles15 problems that come from them using SP1 instead of SP3+updates.
So yes, paying customers really like old stuff :-)
Or you just did not sell it well enough. Maintenance costs for an aging car rise to the point where getting a new one is more economical. At this very price-parity point, one would surely pick the one that looks nicer.
On Fri, Jan 07, Jan Engelhardt wrote:
On Friday 2022-01-07 10:47, Stefan Seyfried wrote:
And yes, I tell them daily to go away and kill themselves when they come around with on their SLES12 installations, that would be simply go away if they switched to SLES15+. Or when they whine about their sles15 problems that come from them using SP1 instead of SP3+updates.
So yes, paying customers really like old stuff :-)
Or you just did not sell it well enough.
Maintenance costs for an aging car rise to the point where getting a new one is more economical. At this very price-parity point, one would surely pick the one that looks nicer.
This is true for the average consumer, but not for data centers. Very often they run into a sitution, where updating all server would be much more expensive then an exorbitant price for maintaining the old code base. Often it is the sheer mass on virtual machines and the missing knowledge about the running workload which prevents them from updating. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Ivo Totev (HRB 36809, AG Nürnberg)
On Fri, 7 Jan 2022 14:02, Thorsten Kukuk <kukuk@...> wrote:
On Fri, Jan 07, Jan Engelhardt wrote:
On Friday 2022-01-07 10:47, Stefan Seyfried wrote:
And yes, I tell them daily to go away and kill themselves when they come around with on their SLES12 installations, that would be simply go away if they switched to SLES15+. Or when they whine about their sles15 problems that come from them using SP1 instead of SP3+updates.
So yes, paying customers really like old stuff :-)
Or you just did not sell it well enough.
Maintenance costs for an aging car rise to the point where getting a new one is more economical. At this very price-parity point, one would surely pick the one that looks nicer.
This is true for the average consumer, but not for data centers. Very often they run into a sitution, where updating all server would be much more expensive then an exorbitant price for maintaining the old code base. Often it is the sheer mass on virtual machines and the missing knowledge about the running workload which prevents them from updating.
Thorsten
May I propose a longterm solution? 1. No distro-shipped python program refers to /usr/bin/python at all, but to /usr/bin/python{version} instead, no hassel with /usr/bin/python. 2. /usr/bin/python is managed by (lib-)alternatives (or similar), for: 2.a: SLE-14.(0..4) this points to /usr/bin/python3.6 2.b: Leap14.4 this point to /usr/bin/python{latest stable} for SLE-15 imho this should not point to a version lower than 3.10 yes, this will lead to recompile of ALL distro included python-stuff, but much less hassel, version-related anger and frustation in the long run. Dislaimer: I'm no expert at python at all, please do not take this proposal as word-of-god, insult to you, or similar, but just as an idea for a longterm way out of this mess. - Yamaban.
Dne 07. 01. 22 v 15:28 Yamaban napsal(a):
May I propose a longterm solution?
1. No distro-shipped python program refers to /usr/bin/python at all, but to /usr/bin/python{version} instead, no hassel with /usr/bin/python.
2. /usr/bin/python is managed by (lib-)alternatives (or similar), for: 2.a: SLE-14.(0..4) this points to /usr/bin/python3.6 2.b: Leap14.4 this point to /usr/bin/python{latest stable} for SLE-15 imho this should not point to a version lower than 3.10
yes, this will lead to recompile of ALL distro included python-stuff, but much less hassel, version-related anger and frustation in the long run.
You are missing what is the real issue with the long-term maintenance of two sets of python-* packages. The difference between Python 3.6 and whatever is the last version of Python is getting so big, that it is getting really complicated to maintain packages able to work with both. There are currently plenty of packages which don't work with numpy which supports python36, tons and tons of documentation is generated by Sphinx, but there are many documents which are either working with old one or the current one, and so we have to keep patching some documentation one way or another. Even keeping python39 and python36 in one Factory was getting rather complicated, so I am really enjoying when we are killing python36 now in Factory. Almost any combination of keeping larger set of Python packages supporting both 3.6 and something over 3.8 requires a lot of additional work. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 How fleeting are all human passions compared to the massive continuity of ducks. -- Dorothy L. Sayers: Gaudy Night
On 1/7/22 17:56, Matěj Cepl wrote:
[..] so I am really enjoying when we are killing python36 now in Factory.
You're welcome to do that sooner than later.
Almost any combination of keeping larger set of Python packages supporting both 3.6 and something over 3.8 requires a lot of additional work.
Agreed. And it's a waste of time. Ciao, Michael.
Am 07.01.22 um 21:06 schrieb Michael Ströder:
On 1/7/22 17:56, Matěj Cepl wrote:
[..] so I am really enjoying when we are killing python36 now in Factory.
You're welcome to do that sooner than later.
It's already done. The staging project for it got merged today. The prjconf for Factory now contains: Macros: %pythons %{?!skip_python3:%{?!skip_python39:python39} %{?!skip_python310:python310} %{?!skip_python38:python38}} :Macros And Factory staging is rebuilding without any python36-foo package from singlespec. No `%define skip_python36 1` necessary anymore.
Almost any combination of keeping larger set of Python packages supporting both 3.6 and something over 3.8 requires a lot of additional work.
At least if you insist on building the same version from the same specfile. I am far from well versed in the SLE/Leap universe, but AFAICS the one specfile fits all approach is not required for SLE/Leap. Because SLE keeps around all those package version updates through maintenance updates, the update model of Leap packages would allow to keep an old version, security patched by a paid SUSE maintainer for the paying customers wanting Python 3.6 beyond its official EOL, and at the same time build a Factory fed, community driven package for Python 3.10 from another specfile in a different package.
Agreed. And it's a waste of time.
Ciao, Michael.
- Ben
Dne 07. 01. 22 v 21:40 Ben Greiner napsal(a):
At least if you insist on building the same version from the same specfile.
Or you have to maintain all packages twice, which doesn't save much work anyway. Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. -- C. A. R. Hoare
On 1/7/22 14:02, Thorsten Kukuk wrote:
On Fri, Jan 07, Jan Engelhardt wrote:
On Friday 2022-01-07 10:47, Stefan Seyfried wrote:
So yes, paying customers really like old stuff :-)
Or you just did not sell it well enough.
Maintenance costs for an aging car rise to the point where getting a new one is more economical. At this very price-parity point, one would surely pick the one that looks nicer.
This is true for the average consumer, but not for data centers. Very often they run into a sitution, where updating all server would be much more expensive then an exorbitant price for maintaining the old code base. Often it is the sheer mass on virtual machines and the missing knowledge about the running workload which prevents them from updating.
Only one of my customers insists on running a single SLE version. And they have really high costs because of this. The reason the responsible IT team can get away with this is that the costs caused in projects are not made transparent. All other of my customers have various versions in production and OS updates are made on case-by-case decisions. This does not mean that it's always easy to do updates. As you said unknown workloads are a big issue. Ciao, Michael.
On 1/7/22 12:26, Jan Engelhardt wrote:
On Friday 2022-01-07 10:47, Stefan Seyfried wrote:
And yes, I tell them daily to go away and kill themselves when they come around with on their SLES12 installations, that would be simply go away if they switched to SLES15+. Or when they whine about their sles15 problems that come from them using SP1 instead of SP3+updates.
So yes, paying customers really like old stuff :-)
Or you just did not sell it well enough.
Maintenance costs for an aging car rise to the point where getting a new one is more economical.
That may be a good analogy on this case. The trick is to know where you have reached that point in which a car replacement is the best option. That may differ a lot for each one of us. And certainly for most enterprise-level users, that is not every a few years, or when the car has just some drawbacks (like not being compatible with the latest Android auto), or when the driver wants to try the new "sport mode" in the newer generation of the car. Let's face it, most ordinary people (home users in our reality) change the car way before reaching that critical point in which maintenance becomes really more expensive than buying. Yes, I know analogies are dangerous. But the pace of major SLE releases and service packs is designed to match current SUSE customers' expectations. A major release every four years with several service packs for each of those releases seems to fit what the enterprise world wants so far. Is not that they adapt to the SLE lifecycle, but the SLE lifecycle is adapted to the market expectations, based on experience. Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions
participants (23)
-
Ancor Gonzalez Sosa -
Axel Braun -
Axel Braun -
Ben Greiner -
Carlos E. R. -
Dan Čermák -
Frans de Boer -
Georg Pfuetzenreuter -
Jan Engelhardt -
Larry Len Rainey -
Martin Wilck -
Martin Wilck -
Mathias Homann -
Matěj Cepl -
Michael Ströder -
Neal Gompa -
rbrown -
Roger Oberholtzer -
Simon Lees -
Stefan Seyfried -
Takashi Iwai -
Thorsten Kukuk -
Yamaban