[opensuse-project] Re: Bringing Leap and SUSE Linux Enterprise closer together - a proposal
i'm (re-, re-re-)reading up on these^ just-announced CloserTogether/NewLeap/Jump plans. given current plans, I'm trying to get a sense for whether we end up with more/less 'flexibility'. i know the question's been/being asked; i don't yet fully understand the answer. i realize the plans are in flux. here's my use-case. for opensuse-based production, none of the current releases -- out of the box -- meet my requirements. instead, currently, use a stable Leap core, with add'l repos -- devel or my own -- as needed. that approach is bumping into evermore significant limitations. particularly around 'base' tech'y. e.g., i use Kernel:Stable on Leap, with a rebuilt base:System Dracut, and the firmware upgrades that install along with it. i've switched to systemd-networkd rather than wicked for network mgmt. PRE-jump plans, Leap 15.2 remains stuck at Systemd v234 -- as that's the stable SLE-15* release. Afaict, it STAYS at that version for the entire 15x lifetime; unless/until there's a security-mandated update. with wireguard now native in-kernel, i'd like to use systemd-networkd's native WG support. but that's NOT available until systemd v>= 237; TW, of course, is at 244/245 already. does this CloserTogether "future" make it more, or less, likely that the 'Jump' release will have the flexibility to swap/enable version upgrades of key/core components -- in this case, systemd? or does Jump continue to stay stuck on old versions, leaving TW as the only choice of released version for newer base/core tech? yes, i can DIY my own opensuse systemd pkgs for Leap. working on it. going less well atm than hoped :-/ far simpler to use a distro that provides that flexibility (do that currently with Arch, and in-house LFS). prefer to have an option for a suse-based solution. is Jump it? -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Freitag, 10. April 2020, 17:44:30 CEST wrote PGNet Dev:
i'm (re-, re-re-)reading up on these^ just-announced CloserTogether/NewLeap/Jump plans.
given current plans, I'm trying to get a sense for whether we end up with more/less 'flexibility'. i know the question's been/being asked; i don't yet fully understand the answer.
i realize the plans are in flux.
here's my use-case.
for opensuse-based production, none of the current releases -- out of the box -- meet my requirements.
instead, currently, use a stable Leap core, with add'l repos -- devel or my own -- as needed.
that approach is bumping into evermore significant limitations.
particularly around 'base' tech'y.
e.g.,
i use Kernel:Stable on Leap, with a rebuilt base:System Dracut, and the firmware upgrades that install along with it.
i've switched to systemd-networkd rather than wicked for network mgmt.
PRE-jump plans, Leap 15.2 remains stuck at Systemd v234 -- as that's the stable SLE-15* release. Afaict, it STAYS at that version for the entire 15x lifetime; unless/until there's a security-mandated update.
with wireguard now native in-kernel, i'd like to use systemd-networkd's native WG support. but that's NOT available until systemd v>= 237; TW, of course, is at 244/245 already.
does this CloserTogether "future" make it more, or less, likely that the 'Jump' release will have the flexibility to swap/enable version upgrades of key/core components -- in this case, systemd?
or does Jump continue to stay stuck on old versions, leaving TW as the only choice of released version for newer base/core tech?
Jump would also stuck. It is not really a difference to use source or binaries from SLE in this regard. Yes, TW is the only way in openSUSE for a distro with newer versions. Well, except that it is seen valuable (and safe) to update in next SLE service pack. But Leap and Jump do not differ here with current plans at least. -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
From: Adrian Schröter [mailto:adrian@suse.de]
or does Jump continue to stay stuck on old versions, leaving TW as the only choice of released version for newer base/core tech? Jump would also stuck. It is not really a difference to use source or binaries from SLE in this regard.
Yes, TW is the only way in openSUSE for a distro with newer versions. Well, except that it is seen valuable (and safe) to update in next SLE service pack.
But Leap and Jump do not differ here with current plans at least.
noted. not the answer i _hoped_ to hear, but not surprising ... (though, imo, hobbling leap 15.2 with outdated systemd right out of the gate is a mistake; but, again, that's me) having the middle ground would, in effect, be an additional distro -- complicating, not simplifying, maintenance, contrary to what i understand the purpose of this^ is in the 1st place. need to stick with alternatives that scratch our itch, i'm afraid. thx 4 clarifying. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
Am Freitag, 10. April 2020, 23:11:33 CEST schrieb PGNet Dev:
From: Adrian Schröter [mailto:adrian@suse.de]
or does Jump continue to stay stuck on old versions, leaving TW as the only choice of released version for newer base/core tech?> Jump would also stuck. It is not really a difference to use source or binaries from SLE in this regard.
Yes, TW is the only way in openSUSE for a distro with newer versions. Well, except that it is seen valuable (and safe) to update in next SLE service pack.
But Leap and Jump do not differ here with current plans at least.
noted.
not the answer i _hoped_ to hear, but not surprising ... (though, imo, hobbling leap 15.2 with outdated systemd right out of the gate is a mistake; but, again, that's me)
As of now there have always been options for a version bump - I guess that will stay. Or even extend Cheers Axel -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On 4/11/20 4:58 PM, Axel Braun wrote:
Am Freitag, 10. April 2020, 23:11:33 CEST schrieb PGNet Dev:
From: Adrian Schröter [mailto:adrian@suse.de]
or does Jump continue to stay stuck on old versions, leaving TW as the only choice of released version for newer base/core tech?> Jump would also stuck. It is not really a difference to use source or binaries from SLE in this regard.
Yes, TW is the only way in openSUSE for a distro with newer versions. Well, except that it is seen valuable (and safe) to update in next SLE service pack.
But Leap and Jump do not differ here with current plans at least.
noted.
not the answer i _hoped_ to hear, but not surprising ... (though, imo, hobbling leap 15.2 with outdated systemd right out of the gate is a mistake; but, again, that's me)
As of now there have always been options for a version bump - I guess that will stay. Or even extend
For core packages, there generally needs to be a really good business reason to justify the extra QA and maintenance costs which are significantly higher for SLE packages as SLE versions are maintained for much longer then Leap ones. SLE customers also expect not too much to change in service packs so its certainly a juggling act. Leap only packages on the other hand are a bit different and much less likely to be a core component which is why maintainers have more flexibility there. The problem with doing a distro half way in between Leap and Tumbleweed, is agreeing what should change and when as everyone has different opinions on what packages should stay the same and which packages should change which makes it very hard to define what the distro should look like. It would also take significant extra man power when Leap and Tumbleweed seem to be meeting the majority of users needs. Have you considered trying tumbleweed, Ive been using it on most of my machines for several years. -- 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 4/11/20 3:06 AM, Simon Lees wrote:
For core packages, there generally needs to be a really good business reason to justify the extra QA and maintenance costs which are significantly higher for SLE packages as SLE versions are maintained for much longer then Leap ones. SLE customers also expect not too much to change in service packs so its certainly a juggling act. Leap only packages on the other hand are a bit different and much less likely to be a core component which is why maintainers have more flexibility there.
Sure. I understand the SLE policy stance, and that it's a distro choice. It's just not one that fits my needs. And why I don't use it for my production svrs. I'd _prefer_ that wasn't the case. That, with this^ proposal, Leap & SLE are 'moving closer', leads to my not-unique question abt what that means to that Leap flexibility ...
The problem with doing a distro half way in between Leap and Tumbleweed, is agreeing what should change and when as everyone has different opinions on what packages should stay the same and which packages should change which makes it very hard to define what the distro should look like.
Of course. My itch != your itch. For _me_, I 'want' that stable but up-to-date core, with little distro thrash, and the option to easily update. Here, that core is, in general: kernel, systemd, grub, dracut, openssl, network mgmt. 'til now, Leap + repos has mostly fit that bill, and has been manageable. But, it's getting more tortured to maintain; hence my questions^ -- and why most of my production is !*suse, despite my _preference_.
It would also take significant extra man power
Not disputing that in the slightest.
when Leap and Tumbleweed seem to be meeting the majority of users needs. As said in sales, "It's the deals you never know you lost ..."
Have you considered trying tumbleweed, Ive been using it on most of my machines for several years.
Sure, it's been considered. For lots of reasons, including those^, not a fit here. -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org
On Fri, 2020-04-10 at 22:36 +0200, Adrian Schröter wrote:
On Freitag, 10. April 2020, 17:44:30 CEST wrote PGNet Dev:
i'm (re-, re-re-)reading up on these^ just-announced CloserTogether/NewLeap/Jump plans.
given current plans, I'm trying to get a sense for whether we end up with more/less 'flexibility'. i know the question's been/being asked; i don't yet fully understand the answer.
i realize the plans are in flux.
here's my use-case.
for opensuse-based production, none of the current releases -- out of the box -- meet my requirements.
instead, currently, use a stable Leap core, with add'l repos -- devel or my own -- as needed.
that approach is bumping into evermore significant limitations.
particularly around 'base' tech'y.
e.g.,
i use Kernel:Stable on Leap, with a rebuilt base:System Dracut, and the firmware upgrades that install along with it.
i've switched to systemd-networkd rather than wicked for network mgmt.
PRE-jump plans, Leap 15.2 remains stuck at Systemd v234 -- as that's the stable SLE-15* release. Afaict, it STAYS at that version for the entire 15x lifetime; unless/until there's a security-mandated update.
with wireguard now native in-kernel, i'd like to use systemd- networkd's native WG support. but that's NOT available until systemd v>= 237; TW, of course, is at 244/245 already.
does this CloserTogether "future" make it more, or less, likely that the 'Jump' release will have the flexibility to swap/enable version upgrades of key/core components -- in this case, systemd?
or does Jump continue to stay stuck on old versions, leaving TW as the only choice of released version for newer base/core tech?
Jump would also stuck. It is not really a difference to use source or binaries from SLE in this regard.
Yes, TW is the only way in openSUSE for a distro with newer versions. Well, except that it is seen valuable (and safe) to update in next SLE service pack.
But Leap and Jump do not differ here with current plans at least.
Let me remind people of tick-tock SLE model. Where second allows greater changes when it comes to SLE/Leap overlapping packages. Same would apply for Jump/Leap. Great systemd update would have to make it to Tock releases. People will have later in year an "official process" to request such change. The sooner and better justification, the greater the chance is.
--
Adrian Schroeter email: adrian@suse.de
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
Maxfeldstraße 5 90409 Nürnberg Germany
-- Best regards Luboš Kocman Release Manager openSUSE Leap SUSE Software Solutions Germany GmbH Maxfeldstr. 5 90409 Nuremberg Germany (HRB 36809, AG Nürnberg) Managing Director: Felix Imendörffer
participants (5)
-
Adrian Schröter -
Axel Braun -
Lubos Kocman -
PGNet Dev -
Simon Lees