Mail (of / with some) Concern(s)
Dear Reader, I have been using both SUSE and OpenSUSE for many, many years. Within my personal computing environment as well as within my professional computing environment (Enterprise Architect is my Job). I've always thought that having a stable branche is the way to go, and stil do. But, there's an increasing concern about usability. Especially with the recent 15.3 release of OpenSUSE (and SUSE Enterprise Linux equivalent). There were always packages that didn't work 100% and needed some kind of fix. However, currently we're seeing a lot of broken things. Either being it something as insignificant as Gradio (no connection to directory services), old version of Evolution with which one can't connect to either iCloud or Gmail services, either being it the introduction of the nouveau driver (and all it's problems with (for example) Quadra Cards). SUSE and OpenSUSE were (to me) about productivity. Which means, not cutting edge, but certainly not broken. And with a lot of versions things are too much outdated and/or broken. So my kind request would be to take this into account when making a next fix for 15.3 and absolutely when working on 15.4 (or whatever the next one will be :-) ). Evolution within a corporate context means: it has to work ... And nowadays we even have companies that run on ... Google infrastructre ... An installation option at which you can easily choose either you wish to use: 1. A Clean GNOME (or KDE or whatever) Environment without any extra drivers 2. A Nouveau version (Open Source) of whatever environment or 3. A version that is ready to be linked with commercial drivers, would be fantastic. We have made the switch to SystemD in the Linux world, together with a lot of "new concepts and ideas". Easy of use was always something one could complement (Open)SUSE for. However, times are changing and the adience is becomming more demanding ... So perhaps a notch newer or with some patches to fix the biggest issues? Just some concerns. Only because I care about SUSE and would like to only improve more and more ... Thank you for the great work so far and: keep up the good work! Best regards, Lukas Pruski
On Mon, Aug 9, 2021 at 5:09 AM Łukasz Pruski <l.pruski@outlook.com> wrote:
Dear Reader,
I have been using both SUSE and OpenSUSE for many, many years. Within my personal computing environment as well as within my professional computing environment (Enterprise Architect is my Job).
I've always thought that having a stable branche is the way to go, and stil do. But, there's an increasing concern about usability. Especially with the recent 15.3 release of OpenSUSE (and SUSE Enterprise Linux equivalent).
There were always packages that didn't work 100% and needed some kind of fix.
However, currently we're seeing a lot of broken things. Either being it something as insignificant as Gradio (no connection to directory services), old version of Evolution with which one can't connect to either iCloud or Gmail services, either being it the introduction of the nouveau driver (and all it's problems with (for example) Quadra Cards).
SUSE and OpenSUSE were (to me) about productivity. Which means, not cutting edge, but certainly not broken. And with a lot of versions things are too much outdated and/or broken.
So my kind request would be to take this into account when making a next fix for 15.3 and absolutely when working on 15.4 (or whatever the next one will be :-) ).
openSUSE Leap 15.3 was the first where we tried this new model for openSUSE Leap development. It didn't go as well as we liked, but we're learning from it and hopefully going to do better for Leap 15.4. One aspect we're trying to improve is coordinating with SLE so that things get done relatively early, and we're doing that with the feature request tracker: https://code.opensuse.org/leap/features I hope this will help us stay on the same page and make development smoother this time. :)
Evolution within a corporate context means: it has to work ... And nowadays we even have companies that run on ... Google infrastructre ...
An installation option at which you can easily choose either you wish to use:
1. A Clean GNOME (or KDE or whatever) Environment without any extra drivers
I'm not sure what you mean here?
2. A Nouveau version (Open Source) of whatever environment or
This one depresses me. The folks at Red Hat who work on Nouveau are basically blocked on Nvidia releasing the signed firmware blobs that were promised years ago. Alas, Nvidia isn't great on keeping such promises.
3. A version that is ready to be linked with commercial drivers, would be fantastic.
This is out of our control to some extent, but we do inherit compatibility for SLE driver packages. If Nvidia provides them for SLE 15 SP3 (and the upcoming 15 SP4), then they'll work with 15.3 (and the upcoming 15.4) respectively. We can't ship it on the DVD, though.
We have made the switch to SystemD in the Linux world, together with a lot of "new concepts and ideas". Easy of use was always something one could complement (Open)SUSE for. However, times are changing and the adience is becomming more demanding ...
So perhaps a notch newer or with some patches to fix the biggest issues? Just some concerns. Only because I care about SUSE and would like to only improve more and more ...
systemd is planned to be rebased to at least v249 for 15.4: https://code.opensuse.org/leap/features/issue/27 -- 真実はいつも一つ！/ Always, there's only one truth!
On 06/08/2021 13.11, Łukasz Pruski wrote:
Dear Reader,
I have been using both SUSE and OpenSUSE for many, many years. Within my personal computing environment as well as within my professional computing environment (Enterprise Architect is my Job).
I've always thought that having a stable branche is the way to go, and stil do. But, there's an increasing concern about usability. Especially with the recent 15.3 release of OpenSUSE (and SUSE Enterprise Linux equivalent).
There were always packages that didn't work 100% and needed some kind of fix.
However, currently we're seeing a lot of broken things. Either being it something as insignificant as Gradio (no connection to directory services), old version of Evolution with which one can't connect to either iCloud or Gmail services, either being it the introduction of the nouveau driver (and all it's problems with (for example) Quadra Cards).
Nvidia doesn't really play nice with Linux. My recommendation is to avoid their hardware and use AMD instead. For email, I switched to Thunderbird eons ago.
SUSE and OpenSUSE were (to me) about productivity. Which means, not cutting edge, but certainly not broken. And with a lot of versions things are too much outdated and/or broken.
Packages on openSUSE leap /have/ to be old. But if you see breakage, report each breakage in Bugzilla, one by one.
So my kind request would be to take this into account when making a next fix for 15.3 and absolutely when working on 15.4 (or whatever the next one will be :-) ).
Evolution within a corporate context means: it has to work ... And nowadays we even have companies that run on ... Google infrastructre ...
An installation option at which you can easily choose either you wish to use:
1. A Clean GNOME (or KDE or whatever) Environment without any extra drivers
I don't understand this. :-?
2. A Nouveau version (Open Source) of whatever environment or
3. A version that is ready to be linked with commercial drivers, would be fantastic.
As far as I know, you can use the proprietary Nvidia drivers, no problem. Just not out of the box, because the box can not contain legally the proprietary drivers, you have to get those yourself. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))
On Mon 2021-08-09, Carlos E. R. wrote:
Packages on openSUSE leap /have/ to be old.
That is simply not true. SLE 15 SP4 / Leap 15.4 are going to bring key updates to the lower levels of the system (including a new kernel version) and the upper half of the cake, as I lovingly call it, can be updated with very few constraints (dependencies being the primary hurdle, which is something we - openSUSE and SUSE - are working to get better in).
But if you see breakage, report each breakage in Bugzilla, one by one.
Agreed. Gerald
On 8/9/21 8:34 PM, Gerald Pfeifer wrote:
On Mon 2021-08-09, Carlos E. R. wrote:
Packages on openSUSE leap /have/ to be old.
That is simply not true. SLE 15 SP4 / Leap 15.4 are going to bring key updates to the lower levels of the system (including a new kernel version) and the upper half of the cake, as I lovingly call it, can be updated with very few constraints (dependencies being the primary hurdle, which is something we - openSUSE and SUSE - are working to get better in).
Which Python 3.x version will be shipped with Leap 15.4? Ciao, Michael.
On 09/08/2021 20.34, Gerald Pfeifer wrote:
On Mon 2021-08-09, Carlos E. R. wrote:
Packages on openSUSE leap /have/ to be old.
That is simply not true. SLE 15 SP4 / Leap 15.4 are going to bring key updates to the lower levels of the system (including a new kernel version) and the upper half of the cake, as I lovingly call it, can be updated with very few constraints (dependencies being the primary hurdle, which is something we - openSUSE and SUSE - are working to get better in).
Well, I put it in italics :-) A lot of stuff in 15.3 is old, as it is basically the same version as in 15.0. I'm very glad to hear that 15.4 will have new versions of things :-)
But if you see breakage, report each breakage in Bugzilla, one by one.
Agreed.
-- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))
Am Dienstag, 10. August 2021, 13:01:52 CEST schrieb Carlos E. R.:
I'm very glad to hear that 15.4 will have new versions of things
I would even see it more aggressive: Everything (Applications etc, not base packages) comes from TW, unless there is a good reason to keep an outdated application. Cheers Axel
On Tue, Aug 10, 2021, at 13:15, Axel Braun wrote:
Am Dienstag, 10. August 2021, 13:01:52 CEST schrieb Carlos E. R.:
I'm very glad to hear that 15.4 will have new versions of things
I would even see it more aggressive: Everything (Applications etc, not base packages) comes from TW, unless there is a good reason to keep an outdated application.
+1 from me. I see no point in keeping four year old applications. A lot can change in four years.. /Syds
Cheers Axel
On Tue, Aug 10, 2021 at 01:33:07PM +0200, Syds Bearda wrote:
On Tue, Aug 10, 2021, at 13:15, Axel Braun wrote:
Am Dienstag, 10. August 2021, 13:01:52 CEST schrieb Carlos E. R.:
I'm very glad to hear that 15.4 will have new versions of things
I would even see it more aggressive: Everything (Applications etc, not base packages) comes from TW, unless there is a good reason to keep an outdated application.
+1 from me. I see no point in keeping four year old applications. A lot can change in four years..
Given that the Leap 15.3+ model is: - take all from SLE - take everything not in SLE from openSUSE Backports + Leap repo If you want SLE packages updated, we need to push this via SLE processes. That said, SLES 15 SP4 is open to version updates if possible. Ciao, Marcus
Le mardi 10 août 2021 à 13:48 +0200, Michael Ströder a écrit :
On 8/10/21 1:39 PM, Marcus Meissner wrote:
If you want SLE packages updated, we need to push this via SLE processes.
Python 3.9+!
Python 3.9 is already part of Leap 15.3, you don't need Leap 15.4 for it. It is not just the system python3 interpreter but you can install it in parallel. -- Frederic Crozat Release Manager SUSE Linux Enterprise SUSE
On Tue, 10 Aug 2021 12:48:47 +0000 Frederic Crozat wrote:
Le mardi 10 août 2021 à 13:48 +0200, Michael Ströder a écrit :
On 8/10/21 1:39 PM, Marcus Meissner wrote:
If you want SLE packages updated, we need to push this via SLE processes.
Python 3.9+!
Python 3.9 is already part of Leap 15.3, you don't need Leap 15.4 for it.
It is not just the system python3 interpreter but you can install it in parallel.
And that works for packages you can pip install into virtualenv. Not sure how well that would work with say, Pandas or Numpy or newest QGIS, with their loads of Python and other dependencies , which are just not available for 3.9 on Leap, AFAIK, and those upstream projects, at least, removed (official) 3.6 support. I am not really affected by this(well, *maybe* QGIS, but I can live with LTR :)), since I use Miniconda for pretty much all of that, but, AFAICT, either the newer 'default' python3 (ain't gonna happen in 15 codestream (https://code.opensuse.org/leap/features/issue/17#comment-286)), or larger selection of packages built for python-3.9 on Leap, if possible, would be, I guess, satisfactory for people that prefer to use OS packages instead of something like Anaconda/Miniconda. Pedja
On 8/10/21 4:42 PM, Predrag Ivanović wrote:
On Tue, 10 Aug 2021 12:48:47 +0000 Frederic Crozat wrote:
Le mardi 10 août 2021 à 13:48 +0200, Michael Ströder a écrit :
On 8/10/21 1:39 PM, Marcus Meissner wrote:
If you want SLE packages updated, we need to push this via SLE processes.
Python 3.9+!
Python 3.9 is already part of Leap 15.3, you don't need Leap 15.4 for it.
It is not just the system python3 interpreter but you can install it in parallel.
And that works for packages you can pip install into virtualenv.
pip install is nice and easy unless you need C wrapper modules for which you have to install all the build tools and library dependencies. (Yes, I know manylinux wheels but that does not work for me.) Currently I maintain my Python modules as openSUSE/SLE packages built in OBS. More and more this gets really annoying for Leap/SLE. Ciao, Michael.
Am 10.08.21 um 16:42 schrieb Predrag Ivanović:
On Tue, 10 Aug 2021 12:48:47 +0000 Frederic Crozat wrote:
Le mardi 10 août 2021 à 13:48 +0200, Michael Ströder a écrit :
On 8/10/21 1:39 PM, Marcus Meissner wrote:
If you want SLE packages updated, we need to push this via SLE processes. Python 3.9+! Python 3.9 is already part of Leap 15.3, you don't need Leap 15.4 for it.
It is not just the system python3 interpreter but you can install it in parallel.
And that works for packages you can pip install into virtualenv. Not sure how well that would work with say, Pandas or Numpy or newest QGIS, with their loads of Python and other dependencies , which are just not available for 3.9 on Leap, AFAIK, and those upstream projects, at least, removed (official) 3.6 support.
I am not really affected by this(well, *maybe* QGIS, but I can live with LTR :)), since I use Miniconda for pretty much all of that, but, AFAICT, either the newer 'default' python3 (ain't gonna happen in 15 codestream (https://code.opensuse.org/leap/features/issue/17#comment-286)), or larger selection of packages built for python-3.9 on Leap, if possible, would be, I guess, satisfactory for people that prefer to use OS packages instead of something like Anaconda/Miniconda.
If SUSE is going to stick with the decision to stay on Python 3.6, they basically tell their SLE customers and Leap users: Use pip/conda or look for another distribution. Furthermore every RPM package with a Python dependency will continue to have to support and require Python modules for 3.6, which is EOL after December 2021. In Tumbleweed, we made it really easy to enable co-installable Python flavors and the specfiles of the interpreters are prepared so that it is really easy to switch the primary python3 provider (regardless if you want to have multiflavor or not). If you are not going to use this in 15.4, you miss out a lot.
Pedja
Ben
On Tue, 2021-08-10 at 22:04 +0200, Ben Greiner wrote:
If SUSE is going to stick with the decision to stay on Python 3.6,
On Tue, 2021-08-10 at 12:48 +0000, Frederic Crozat wrote:
Python 3.9 is already part of Leap 15.3, you don't need Leap 15.4 for it.
Seriously, why post about whether SUSE is going to stick with Python 3.6 when you ALREADY have a SUSE Release Manager, for SLE no less, who was involved in SLE 15 SP3 no less, telling you ALREADY that Python 3.9 is in Leap 15.3? Please save the electrons and everyones time reading these threads and refrain from rehashing concerns that have already been addressed.
Am 10.08.21 um 22:15 schrieb Richard Brown:
On Tue, 2021-08-10 at 22:04 +0200, Ben Greiner wrote:
If SUSE is going to stick with the decision to stay on Python 3.6, On Tue, 2021-08-10 at 12:48 +0000, Frederic Crozat wrote: Python 3.9 is already part of Leap 15.3, you don't need Leap 15.4 for it.
Seriously, why post about whether SUSE is going to stick with Python 3.6 when you ALREADY have a SUSE Release Manager, for SLE no less, who was involved in SLE 15 SP3 no less, telling you ALREADY that Python 3.9 is in Leap 15.3?
Sorry, but this is always the same problem of these conversations: You fail to acknowledge that the interpreter != packages ! From the already linked https://code.opensuse.org/leap/features/issue/17#comment-286: "We did receive a confirmation from maintainer that plan for the default python is to remain at 3.6. We offer "limited" availability of python39 stack and that's the situation we'd like to keep in code stream 15." Yes, you have the Python 3.9 interpreter. But it is worthless for all RPM packages remotely requiring anything of Python beyond the stdlib.
On Tue, 2021-08-10 at 22:23 +0200, Ben Greiner wrote:
"We did receive a confirmation from maintainer that plan for the default python is to remain at 3.6. We offer "limited" availability of python39 stack and that's the situation we'd like to keep in code stream 15."
It's a core, rarely (if ever) compromised requirement of any enterprise-stable Linux operating system that something built for a major version of that operating system keeps on working on subsequent service packs of that release. That is where the need to keep python3.6 as the primary interpreter comes from. That level of stability is what everyone wanted when they demanded more stability and opted for an increased closeness to SLE. That's what they get. My opinion on Regular Releases is well documented [1], they are not for me, but those who disagree with me shouldn't bemoan the consequences of getting what they wish for. [1] https://rootco.de/2020-02-10-regular-releases-are-wrong/
If I combine this: Am 10.08.21 um 22:29 schrieb Richard Brown:
It's a core, rarely (if ever) compromised requirement of any enterprise-stable Linux operating system that something built for a major version of that operating system keeps on working on subsequent service packs of that release.
That is where the need to keep python3.6 as the primary interpreter comes from.
with this: Am 10.08.21 um 22:27 schrieb Matěj Cepl:
I cannot say more about our future products, but I am afraid co-installable Python flavours won't be in SLE-15SP4.
Then this: Am 09.08.21 um 20:34 schrieb Gerald Pfeifer:
On Mon 2021-08-09, Carlos E. R. wrote:
Packages on openSUSE leap /have/ to be old. That is simply not true. SLE 15 SP4 / Leap 15.4 are going to bring key updates to the lower levels of the system (including a new kernel version) and the upper half of the cake, as I lovingly call it, can be updated with very few constraints (dependencies being the primary hurdle, which is something we - openSUSE and SUSE - are working to get better in).
is quite an overstatement. In the end it comes back to the fact that you have to tell people like Łukasz or Michael Ströder that they have to move to another distribution if they want a non EOL stack. Other distributions provide LTS releases with a much more recent freeze point. So be it. I am a happy TW user and I am looking forward to the day when nobody ever again tells me to "fix the Leap build" (for :backports) in a Factory submit request. Ben
On 10/08/2021 22.29, Richard Brown wrote:
On Tue, 2021-08-10 at 22:23 +0200, Ben Greiner wrote:
"We did receive a confirmation from maintainer that plan for the default python is to remain at 3.6. We offer "limited" availability of python39 stack and that's the situation we'd like to keep in code stream 15."
It's a core, rarely (if ever) compromised requirement of any enterprise-stable Linux operating system that something built for a major version of that operating system keeps on working on subsequent service packs of that release.
That is where the need to keep python3.6 as the primary interpreter comes from.
That level of stability is what everyone wanted when they demanded more stability and opted for an increased closeness to SLE.
Eum... No, I did not demand more stability or increase closeness to SLE. Maybe others did, but not me, so not everyone. I was more or less happy with the model before Leap. I understand that it can not be maintained with our current workforce, but that was the model I liked. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))
Am 11.08.21 um 00:48 schrieb Carlos E. R.:
On 10/08/2021 22.29, Richard Brown wrote:
On Tue, 2021-08-10 at 22:23 +0200, Ben Greiner wrote:
"We did receive a confirmation from maintainer that plan for the default python is to remain at 3.6. We offer "limited" availability of python39 stack and that's the situation we'd like to keep in code stream 15."
It's a core, rarely (if ever) compromised requirement of any enterprise-stable Linux operating system that something built for a major version of that operating system keeps on working on subsequent service packs of that release.
That is where the need to keep python3.6 as the primary interpreter comes from.
That level of stability is what everyone wanted when they demanded more stability and opted for an increased closeness to SLE.
Eum... No, I did not demand more stability or increase closeness to SLE. Maybe others did, but not me, so not everyone.
Same here. I heard no openSUSE 42.3 users complaining about stability, and there were no surveys I can remember. For me, "1-2 years old packages at release date" replaced with "3-4 year old packages at release date" is a bad deal, and I really doubt it increases stability. Having a SLE kernel with all its backports is a good thing, but for the whole rest... Stating that "Closing-the-leap-gap" is done because of the demand of the openSUSE users is quite a bold statement. Between enterprise users which only demand ultra-stable and certified software and reckless TW users, there is really a huge gap. It should be filled by the Leap releases, IMO.
I was more or less happy with the model before Leap. I understand that it can not be maintained with our current workforce, but that was the model I liked.
On Tuesday 2021-08-10 22:15, Richard Brown wrote:
On Tue, 2021-08-10 at 22:04 +0200, Ben Greiner wrote:
If SUSE is going to stick with the decision to stay on Python 3.6,
Python 3.9 is already part of Leap 15.3, you don't need Leap 15.4 for it.
Seriously, why post about whether SUSE is going to stick with Python 3.6 when you ALREADY have a SUSE Release Manager, for SLE no less, who was involved in SLE 15 SP3 no less, telling you ALREADY that Python 3.9 is in Leap 15.3?
It may have python39, but, at least for my use case, it is very limited use. 1. I have scripts that "#!/usr/bin/python3". /usr/bin/python3 is fully controlled by python3-base only. It's not update-alternatived by the looks of it, so python 3.9 won't get used without modifying the script or playing games with $PATH. 2. Even if I managed to make it use py39, the script uses something like `import click`. And there is no sign of python39-click in 15.3 that one could install. 3. Rebuilding python packages produces just the python3(6) version again, because python-rpm-macros's %pythons macro does not mention python39. rpm --eval %pythons That's a lot of stones that are in the way for getting my middleware stuff to use a contemporary py runtime.
Dne 11. 08. 21 v 0:34 Jan Engelhardt napsal(a):
That's a lot of stones that are in the way for getting my middleware stuff to use a contemporary py runtime.
What Richard Brown said. If you need latest and greatest, use Tumbleweed. It is not Fedora Rawhide, which is said to eat your babies (not sure, whether it is still so bad). There are plenty of people who use it even for the production installations. SLE (and Leap) is for those who don't care about the latest and greatest, but prefer stability. Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Just speak very loudly and quickly, and state your position with utter conviction, as the French do, and you’ll have a marvelous time! -- Julia Child
On Mi, 2021-08-11 at 00:42 +0200, Matěj Cepl wrote:
Dne 11. 08. 21 v 0:34 Jan Engelhardt napsal(a):
That's a lot of stones that are in the way for getting my middleware stuff to use a contemporary py runtime.
What Richard Brown said. If you need latest and greatest, use Tumbleweed. It is not Fedora Rawhide, which is said to eat your babies (not sure, whether it is still so bad). There are plenty of people who use it even for the production installations.
SLE (and Leap) is for those who don't care about the latest and greatest, but prefer stability.
If 3.6 EOL is reached in 2021, stability demands that we and our users migrate to a more recent version rather sooner than later. And that means that we need to ship a full set of python modules for 3.9. We must still ship 3.6 in 15.4, and I guess it's ok to default to it, but we should provide the framework for our users to migrate to a maintained pythonn version if they so desire. Martin
On 8/11/21 12:26 PM, Martin Wilck wrote:
On Mi, 2021-08-11 at 00:42 +0200, Matěj Cepl wrote:
SLE (and Leap) is for those who don't care about the latest and greatest, but prefer stability.
If 3.6 EOL is reached in 2021, stability demands that we and our users migrate to a more recent version rather sooner than later. And that means that we need to ship a full set of python modules for 3.9.
Full ack. Otherwise Leap becomes more and more unusable for running Python stuff. Ciao, Michael.
On Tuesday 2021-08-10 22:15, Richard Brown wrote:
On Tue, 2021-08-10 at 22:04 +0200, Ben Greiner wrote:
If SUSE is going to stick with the decision to stay on Python 3.6,
Python 3.9 is already part of Leap 15.3, you don't need Leap 15.4 for it. Seriously, why post about whether SUSE is going to stick with Python 3.6 when you ALREADY have a SUSE Release Manager, for SLE no less, who was involved in SLE 15 SP3 no less, telling you ALREADY that Python 3.9 is in Leap 15.3? It may have python39, but, at least for my use case, it is very limited use.
1. I have scripts that "#!/usr/bin/python3". /usr/bin/python3 is fully controlled by python3-base only. It's not update-alternatived by the looks of it, so python 3.9 won't get used without modifying the script or playing games with $PATH. That's intentional. If your middleware needs the non-primary python3,
Am 11.08.21 um 00:34 schrieb Jan Engelhardt: then it must declare so in its script-interpreter-lines. Upstream often has the #!/usr/bin/env python and assumes you play games with $PATH or have a virtualenv. But our RPM specfiles specifically change this line because we provide *system* packages.
2. Even if I managed to make it use py39, the script uses something like `import click`. And there is no sign of python39-click in 15.3 that one could install.
3. Rebuilding python packages produces just the python3(6) version again, because python-rpm-macros's %pythons macro does not mention python39. rpm --eval %pythons
That's a lot of stones that are in the way for getting my middleware stuff to use a contemporary py runtime.
Thank you for providing a living example. Exactly my point. If you ignore Matej's "I am afraid co-installable Python flavours won't be in SLE-15SP4.", you could `%define pythons python39 python39` in every single python-X package in the dependency tree of your middleware so that the singlespec enabled spec files provide additional python39-X packages. Of course this would be easier if that definition would be provided distro-wide, but apparently this is not desired. Ben
Dne 10. 08. 21 v 22:04 Ben Greiner napsal(a):
If SUSE is going to stick with the decision to stay on Python 3.6, they basically tell their SLE customers and Leap users: Use pip/conda or look for another distribution.
Yes, that's the nature of enterprise Linux distribution. Most of our customers prefer predictability and stability to being up-to-date, because they have their workflow which they don't want to touch for how-many-years-we-support-SLE. I know that for non-enterprise users it is hard to swallow, but that's a reality. To make the situation slightly more palatable for Leap users (and enterprise developers who are in the similar situation), we provide also the latest released version of Python with setuptools and pip (3.9 at this moment, and hoping for 3.10 for SP4, if various schedules work together), so that you can easily use pip and still have at least the basic interpreter (which is where most security bugs are) supported by us. We all, SUSE, Red Hat, Oracle, Debian, Ubuntu work on resolving this problem of “too fast/too slow”, but there is no good solution for it.
Furthermore every RPM package with a Python dependency will continue to have to support and require Python modules for 3.6, which is EOL after December 2021.
Yes. We still support Python 2.6 for SLE-11 (with very specialized and expensive support contract).
In Tumbleweed, we made it really easy to enable co-installable Python flavors and the specfiles of the interpreters are prepared so that it is really easy to switch the primary python3 provider (regardless if you want to have multiflavor or not). If you are not going to use this in 15.4, you miss out a lot.
I cannot say more about our future products, but I am afraid co-installable Python flavours won't be in SLE-15SP4. Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mcepl@ceplovi.cz GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8 Basically, the only “intuitive” interface is the nipple. After that, it's all learned. -- Bruce Ediger when discussing intuivity of Mac OS http://groups.google.com/group/comp.sys.next.advocacy\ /msg/7fa8c580900353d0
On Tue 2021-08-10, Marcus Meissner wrote:
Given that the Leap 15.3+ model is:
- take all from SLE - take everything not in SLE from openSUSE Backports + Leap repo
If you want SLE packages updated, we need to push this via SLE processes.
And if you want other packages updated, push them into openSUSE Backports. That's not going to happen automagically, someone's still got to do the work. :) Gerald
Am Dienstag, 10. August 2021, 13:51:35 CEST schrieb Gerald Pfeifer:
On Tue 2021-08-10, Marcus Meissner wrote:
Given that the Leap 15.3+ model is:
- take all from SLE - take everything not in SLE from openSUSE Backports + Leap repo
If you want SLE packages updated, we need to push this via SLE processes.
And if you want other packages updated, push them into openSUSE Backports. That's not going to happen automagically, someone's still got to do the work. :)
Hm...we used to have rolling devel model for Leap, packages just got 'frozen' at beta or RC state. Should not be rocket science to get this back, no? Cheers Axel
Le mardi 10 août 2021 à 14:47 +0200, Axel Braun a écrit :
Am Dienstag, 10. August 2021, 13:51:35 CEST schrieb Gerald Pfeifer:
On Tue 2021-08-10, Marcus Meissner wrote:
Given that the Leap 15.3+ model is:
- take all from SLE - take everything not in SLE from openSUSE Backports + Leap repo
If you want SLE packages updated, we need to push this via SLE processes.
And if you want other packages updated, push them into openSUSE Backports. That's not going to happen automagically, someone's still got to do the work. :)
Hm...we used to have rolling devel model for Leap, packages just got 'frozen' at beta or RC state.
And it wasn't sustainable.
Should not be rocket science to get this back, no?
What you are describing is Tumbleweed. -- Frederic Crozat Release Manager SUSE Linux Enterprise SUSE
Am Dienstag, 10. August 2021, 14:49:29 CEST schrieb Frederic Crozat: ....
Hm...we used to have rolling devel model for Leap, packages just got 'frozen' at beta or RC state.
And it wasn't sustainable.
Why do you think so? Leap before 15.3 was running well.....
Should not be rocket science to get this back, no?
What you are describing is Tumbleweed.
No, as TW does not have a beta or RC phase. I think Ludwig or Lubos should be able to explain / recap the history Cheers Axel
Le mardi 10 août 2021 à 14:53 +0200, Axel Braun a écrit :
Am Dienstag, 10. August 2021, 14:49:29 CEST schrieb Frederic Crozat:
....
Hm...we used to have rolling devel model for Leap, packages just got 'frozen' at beta or RC state.
And it wasn't sustainable.
Why do you think so? Leap before 15.3 was running well.....
Leap before 15.3 was not rolling. Some packages where taken from SLE, some from Factory and some from specific projects.
Should not be rocket science to get this back, no?
What you are describing is Tumbleweed.
No, as TW does not have a beta or RC phase. I think Ludwig or Lubos should be able to explain / recap the history
Being one of the guys doing various talks at conferences about how we do release at SUSE (and openSUSE), I think I know how we do those releases ;) -- Frederic Crozat Release Manager SUSE Linux Enterprise SUSE
On 10/08/2021 14.56, Frederic Crozat wrote:
Le mardi 10 août 2021 à 14:53 +0200, Axel Braun a écrit :
Am Dienstag, 10. August 2021, 14:49:29 CEST schrieb Frederic Crozat:
....
Hm...we used to have rolling devel model for Leap, packages just got 'frozen' at beta or RC state.
And it wasn't sustainable.
Why do you think so? Leap before 15.3 was running well.....
Leap before 15.3 was not rolling. Some packages where taken from SLE, some from Factory and some from specific projects.
No, before Leap, up to 13.x. openSUSE back then it was based on a frozen factory, passing alpha and beta phases, then release, and then maintenance, independently of SLE. I'm not proposing to go back to that model, I'm aware of the problems and that it can't be sustained with our manpower. But I have to say that I liked that model more. -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))
On Tue, Aug 10, 2021 at 3:54 PM Axel Braun <axel.braun@gmx.de> wrote:>
Am Dienstag, 10. August 2021, 14:49:29 CEST schrieb Frederic Crozat:
....
Hm...we used to have rolling devel model for Leap, packages just got 'frozen' at beta or RC state.
And it wasn't sustainable.
Why do you think so? Leap before 15.3 was running well.....
Should not be rocket science to get this back, no?
What you are describing is Tumbleweed.
No, as TW does not have a beta or RC phase.
It just needs someone to backport fixes for the next 2 years. As I understand it, lack of manpower was the primary reason for tacking on SLE. And if instead of backporting fixes you will provide new versions this will be TW.
On Dienstag, 10. August 2021 13:51:35 CEST Gerald Pfeifer wrote:
On Tue 2021-08-10, Marcus Meissner wrote:
Given that the Leap 15.3+ model is:
- take all from SLE - take everything not in SLE from openSUSE Backports + Leap repo
If you want SLE packages updated, we need to push this via SLE processes.
And if you want other packages updated, push them into openSUSE Backports. That's not going to happen automagically, someone's still got to do the work. :)
Gerald
Hm, do I have to SR to Backports or to Leap? In https://en.opensuse.org/openSUSE:Packaging_for_Leap is written: How to upgrade a package in an openSUSE Leap release in development All upgrade / updates requests should be sent against openSUSE:Leap:15.3 project. Submit request redirection will automatically redirect request to a project of the package origin (openSUSE:Backports*, SUSE:SLE*, or in very few cases openSUSE:Leap:15.3+). In case of SUSE:SLE submit request will have to be mirrored to SUSE's Internal OBS instance (IBS). -- Mit freundlichen Gruessen, Andreas Vetter
On 8/10/21 10:59 PM, Andreas Vetter wrote:
On Dienstag, 10. August 2021 13:51:35 CEST Gerald Pfeifer wrote:
On Tue 2021-08-10, Marcus Meissner wrote:
Given that the Leap 15.3+ model is:
- take all from SLE - take everything not in SLE from openSUSE Backports + Leap repo
If you want SLE packages updated, we need to push this via SLE processes.
And if you want other packages updated, push them into openSUSE Backports. That's not going to happen automagically, someone's still got to do the work. :)
Gerald
Hm, do I have to SR to Backports or to Leap? In https://en.opensuse.org/openSUSE:Packaging_for_Leap is written: How to upgrade a package in an openSUSE Leap release in development
All upgrade / updates requests should be sent against openSUSE:Leap:15.3 project. Submit request redirection will automatically redirect request to a project of the package origin (openSUSE:Backports*, SUSE:SLE*, or in very few cases openSUSE:Leap:15.3+). In case of SUSE:SLE submit request will have to be mirrored to SUSE's Internal OBS instance (IBS).
The only way to submit things to an already released product such as 15.3 is through the maintenance process, before release submitting to openSUSE:Leap:15.3 would push it to the appropriate place which was backports, when Lubos and team have 15.4 ready enough to receive update requests i'm sure we will get an email here with any updates to the process. -- 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
Le 10/08/2021 à 13:15, Axel Braun a écrit :
Am Dienstag, 10. August 2021, 13:01:52 CEST schrieb Carlos E. R.:
I'm very glad to hear that 15.4 will have new versions of things
I would even see it more aggressive: Everything (Applications etc, not base packages) comes from TW, unless there is a good reason to keep an outdated application.
Cheers Axel
what about fearless update, then? jdd -- http://dodin.org
participants (22)
-
Andreas Vetter -
Andrei Borzenkov -
Axel Braun -
Axel Braun -
Ben Greiner -
Carlos E. R. -
Carlos E. R. -
Frederic Crozat -
Gerald Pfeifer -
Jan Engelhardt -
jdd＠dodin.org -
Manfred Schwarb -
Marcus Meissner -
Martin Wilck -
Matěj Cepl -
Michael Ströder -
Neal Gompa -
Predrag Ivanović -
Richard Brown -
Simon Lees -
Syds Bearda -
Łukasz Pruski