openSUSE ALP: Current Status & A Starting Point for Future Discussions
Hello everyone, I wanted to write this mail to let everyone know the current status of SUSE's ALP (Adaptable Linux Platform) efforts and hopefully get the ball rolling with openSUSE making use of these efforts. This is a long mail, but I've done my best to be brief and shift the more esoteric technical detail as an appendix for those most interested in contributing. First, I want to clear up "What is SUSE ALP?" SUSE ALP is not a single new product by SUSE, in the same way that SLE isn't a single product. Just like now where SUSE has SLES, SLED, SLE Micro, SLE for SAP and more, SUSE ALP is a 'platform' that is going to produce whole families of products. The key defining difference between SLE and ALP though is that SUSE is building ALP with "Adaptability" being an absolute core aspect. This should reduce or eliminate the situation we often see with SLE, where products are 'stuck' using the same versions of core components like glibc and python for the whole lifespan of a codebase. With ALP, SUSE will be building things in a way where different ALP products can have different versions of core components, be supported for different lengths of times, and with old versions of those components be removed when they're no longer needed. This is also why you do not hear about a singular ALP 'codebase', because the way ALP Products are built they potentially could draw from multiple codebases, potentially with very different lifecycles; eg. One ALP Product may be what most would call a very 'stable' distribution, another could be 'rolling', and a third could be a hybrid between the two. I feel this is the most exciting thing about ALP, and it's the most interesting engineering aspect of ALP as it dramatically changes HOW we build these products in OBS. See the appendix for details. So, if ALP is not a single product, what is SUSE building? SUSE's current efforts are focused on two SUSE ALP products, which you can currently see in OBS as SUSE:ALP:Products:Bedrock and :Micro. These names are unlikely to be final, but they are expected to be server-focused products, heavily leaning on transactional-updates and containerisation to even further push the core "Adaptability" goals of ALP; It's far easier to shift and swap what versions of libaries are in play when (almost) everything using them is containerised and the OS is being thought of as a cohesive unit that is updated in atomic operations These will not be the only two products SUSE builds from ALP, but it's a starting point. Going forward, just like for the SLE family of products, the primary build environment for these products is going to have to be SUSE's internal build service. This is so SUSE can have these commercial ALP offerings certified the way they are required to be. However, we want ALP, both the code AND the different way of building things, to be available to openSUSE and ideally reused/adapted for openSUSE's own offerings. We still want to build ALP in the _open_ in addition to what we need to do for SUSE's commercial offerings. Therefore, the current working plan is as follows: - All SUSE ALP Products will be built in SUSE's Internal Build Service, using sources that originated from openSUSE:Factory - All packages used to build SUSE ALP Products will be copied to openSUSE's Open Build Service without alteration - All SUSE ALP Products will be copied from SUSE's IBS to openSUSE's OBS with the only alterations being the obvious necessary rebranding - Any future changes to the SUSE's ALP development workflow (eg. the possible future introduction of a git-based workflow for submitting changes into IBS/OBS) would be also introduced for any openSUSE ALP Products This should all sound very familiar because it's very similar in concept to what we already do with Leap Micro I would like to make the following suggestion to openSUSE on the next steps it could take to extend the above. Any new openSUSE distribution, such as the ones discussed as https://en.opensuse.org/Portal:16.0 or https://en.opensuse.org/openSUSE:ALP/Workgroups/GrassyKnoll should be built as seperate "Products" using the new ALP way of building things. The ALP concept should be flexible enough that these openSUSE Products will be able to leverage all the stuff SUSE is doing for SUSE's ALP Products, but then we (community) can add anything we want. If we find it is not flexible enough, then we (SUSE) will work to adapt it to make it possible for the community to build what it wants. So, if we the community want to build something like old Leap, that should be totally technically feasible. I can certanly imagine the community building something with a stable release cadence and that doesn't use transactional-updates and containers to run everything. If that's the direction we as a community want to go, we should be able to get started soon when the above is in place in OBS. The biggest challenge I forsee would be ensuring we have enough people to maintain all the packages in that 'old fashioned' way of doing things, especially with SUSE going in a different direction...but that has always been an aspect of openSUSE's way of doing things. I could also see a future where we take this opportunity to try something like an ALP-based take on the MicroOS Desktop, more polished, opinionated and less 'tinkering friendly' than old Leap. I'd imagine that would certainly be possible; also, maybe in parallel, if people want to build it. This approach would also tie in nicely with all the awesome work the Agama (formerly known as 'D-Installer') team have been doing, as we should be able to offer a single installation ISO that offers all the combined "openSUSE ALP" offerings, including the 1:1 openSUSE copies of SUSE's Products as well as any additional ones built purely by openSUSE. This would potentially cut out a lot of the work needed for the openSUSE-only Products as (speaking from experience), creating and maintaining installation media is often the biggest pain. What does everyone think? --- Richard Brown Distributions Architect @ SUSE --- APPENDIX Below --- Brief technical details about how ALP is currently built. If the above proposal is widely accepted then openSUSE would mimic the below, just obviously replacing SUSE: with openSUSE: SUSE:ALP:Workbench:<workbench_version> This project effectively does the same job as Factory Rings 0 and 1, being a frozen copy of packages needed to bootstrap everything else. These packages are frozen from openSUSE:Factory SUSE:ALP:Source The main project for OBS prjconfig SUSE:ALP:Source:Standard ALP supports the concept of multiple codebase velocities. "Standard" is the default that SUSE is currently building, but there may be faster or slower velocities going forward. openSUSE may also have it's own in addition. I can totally imagine Tumbleweed evolving to become something like SUSE:ALP:Source:Fast someday. This project includes sources but is not built. SUSE:ALP:Source:Standard:Core:<core_version> Core system packages (linked from SUSE:ALP:Source:Standard) and generic containers to be used across multiple ALP products are built here SUSE:ALP:Products:<product_name>:<product_version>[:<product_minor_version>] This is where the product definitions and patterns live. Each product builds against a SUSE:ALP:Source:<velocity>:Core:<core_version> project Additional packages specific to a product are allowed Ideally packages should be submitted to and linked from :Core: by default (to allow package sharing between products) but exceptions can be made. For openSUSE-only products, such exceptions might be the norm. Containers, VM images, etc specific to a Product are all defined and built here. SUSE:ALP:Products:<product_name>:<product_version>[:<product_minor_version>]:Update If a product will be maintained using a SLE/Leap-like maintenance process, then this would be the Update project for such a process.
On Tue, 2023-04-18 at 17:49 +0200, Richard Brown wrote:
Hello everyone,
I wanted to write this mail to let everyone know the current status of SUSE's ALP (Adaptable Linux Platform) efforts and hopefully get the ball rolling with openSUSE making use of these efforts.
This is a long mail, but I've done my best to be brief and shift the more esoteric technical detail as an appendix for those most interested in contributing.
First, I want to clear up "What is SUSE ALP?"
SUSE ALP is not a single new product by SUSE, in the same way that SLE isn't a single product. Just like now where SUSE has SLES, SLED, SLE Micro, SLE for SAP and more, SUSE ALP is a 'platform' that is going to produce whole families of products.
The key defining difference between SLE and ALP though is that SUSE is building ALP with "Adaptability" being an absolute core aspect. This should reduce or eliminate the situation we often see with SLE, where products are 'stuck' using the same versions of core components like glibc and python for the whole lifespan of a codebase.
With ALP, SUSE will be building things in a way where different ALP products can have different versions of core components, be supported for different lengths of times, and with old versions of those components be removed when they're no longer needed.
This is also why you do not hear about a singular ALP 'codebase', because the way ALP Products are built they potentially could draw from multiple codebases, potentially with very different lifecycles; eg. One ALP Product may be what most would call a very 'stable' distribution, another could be 'rolling', and a third could be a hybrid between the two.
I feel this is the most exciting thing about ALP, and it's the most interesting engineering aspect of ALP as it dramatically changes HOW we build these products in OBS. See the appendix for details.
So, if ALP is not a single product, what is SUSE building?
SUSE's current efforts are focused on two SUSE ALP products, which you can currently see in OBS as SUSE:ALP:Products:Bedrock and :Micro. These names are unlikely to be final, but they are expected to be server-focused products, heavily leaning on transactional-updates and containerisation to even further push the core "Adaptability" goals of ALP; It's far easier to shift and swap what versions of libaries are in play when (almost) everything using them is containerised and the OS is being thought of as a cohesive unit that is updated in atomic operations These will not be the only two products SUSE builds from ALP, but it's a starting point.
Going forward, just like for the SLE family of products, the primary build environment for these products is going to have to be SUSE's internal build service. This is so SUSE can have these commercial ALP offerings certified the way they are required to be.
However, we want ALP, both the code AND the different way of building things, to be available to openSUSE and ideally reused/adapted for openSUSE's own offerings. We still want to build ALP in the _open_ in addition to what we need to do for SUSE's commercial offerings.
Therefore, the current working plan is as follows:
- All SUSE ALP Products will be built in SUSE's Internal Build Service, using sources that originated from openSUSE:Factory - All packages used to build SUSE ALP Products will be copied to openSUSE's Open Build Service without alteration - All SUSE ALP Products will be copied from SUSE's IBS to openSUSE's OBS with the only alterations being the obvious necessary rebranding - Any future changes to the SUSE's ALP development workflow (eg. the possible future introduction of a git-based workflow for submitting changes into IBS/OBS) would be also introduced for any openSUSE ALP Products
This should all sound very familiar because it's very similar in concept to what we already do with Leap Micro
I would like to make the following suggestion to openSUSE on the next steps it could take to extend the above.
Any new openSUSE distribution, such as the ones discussed as https://en.opensuse.org/Portal:16.0 or https://en.opensuse.org/openSUSE:ALP/Workgroups/GrassyKnoll should be built as seperate "Products" using the new ALP way of building things.
The ALP concept should be flexible enough that these openSUSE Products will be able to leverage all the stuff SUSE is doing for SUSE's ALP Products, but then we (community) can add anything we want. If we find it is not flexible enough, then we (SUSE) will work to adapt it to make it possible for the community to build what it wants.
So, if we the community want to build something like old Leap, that should be totally technically feasible. I can certanly imagine the community building something with a stable release cadence and that doesn't use transactional-updates and containers to run everything. If that's the direction we as a community want to go, we should be able to get started soon when the above is in place in OBS.
Given the model you've described and the recently rising popularity of Leap 15.4 there is a rising demand for "old Leap". The plan discussed within our team (Early Enablement) is essentially "forking: Tumbleweed with both non-transactional-update and transactional-update variants, while basing the core on (open)SUSE:ALP binaries as a continuation of the Leap 15.X heritage. Simon's work on the Grassy Knoll over Hackweek is prepping the ground for the way we want to go with Leap 16. I'm not completely putting off the option to do 15.6 if things go south, but it seems that everybody on the team would prefer to go Leap 16.0, especially, since there would be a migration path and quite long overlap for more than a year, based on the current ALP schedule.
The biggest challenge I forsee would be ensuring we have enough people to maintain all the packages in that 'old fashioned' way of doing things, especially with SUSE going in a different direction...but that has always been an aspect of openSUSE's way of doing things.
Yes this is definitely a challenge. Aside from contributors I see it especially on the openSUSE maintenance side and QA. We'll need a lot of help from volunteers. But that was always the case.
I could also see a future where we take this opportunity to try something like an ALP-based take on the MicroOS Desktop, more polished, opinionated and less 'tinkering friendly' than old Leap. I'd imagine that would certainly be possible; also, maybe in parallel, if people want to build it.
Part of the discussed plan described above is also to have a "More stable" MicroOS as one of the images, just like in Tumbleweed. I think there is increase on popularity (/me being one of users).
This approach would also tie in nicely with all the awesome work the Agama (formerly known as 'D-Installer') team have been doing, as we should be able to offer a single installation ISO that offers all the combined "openSUSE ALP" offerings, including the 1:1 openSUSE copies of SUSE's Products as well as any additional ones built purely by openSUSE. This would potentially cut out a lot of the work needed for the openSUSE-only Products as (speaking from experience), creating and maintaining installation media is often the biggest pain.
The model you've described will in a way increase the amount of distributions, from the "setup perspective", not necessarily from package maintenance side, nor install media.. We can already see that on Leap Micro, where we only have to care about branding, and setup twice a year. And given the resources and volunteeres, fully functioning setup in time is the biggest challenge.
What does everyone think?
Given the changes and situation. it Sounds like the best plan to me, or at least the plan where we'll please most of the users as well as contributors. There will be talks on Labs as well as oSC2023 from Simon *Grassy Knoll and Leap 16.0 Planning (me and Max), where we'd like to elaborate on the mentioned proposal. [0] https://events.opensuse.org/conferences/oSC23 [1] https://hackweek.opensuse.org/projects/create-an-alp-based-leap-replacement-... Thank you for a nice summary Richard! Lubos Kocman openSUSE Leap Release Manager
--- Richard Brown Distributions Architect @ SUSE
--- APPENDIX Below ---
Brief technical details about how ALP is currently built. If the above proposal is widely accepted then openSUSE would mimic the below, just obviously replacing SUSE: with openSUSE:
SUSE:ALP:Workbench:<workbench_version> This project effectively does the same job as Factory Rings 0 and 1, being a frozen copy of packages needed to bootstrap everything else. These packages are frozen from openSUSE:Factory
SUSE:ALP:Source The main project for OBS prjconfig
SUSE:ALP:Source:Standard ALP supports the concept of multiple codebase velocities. "Standard" is the default that SUSE is currently building, but there may be faster or slower velocities going forward. openSUSE may also have it's own in addition. I can totally imagine Tumbleweed evolving to become something like SUSE:ALP:Source:Fast someday. This project includes sources but is not built.
SUSE:ALP:Source:Standard:Core:<core_version> Core system packages (linked from SUSE:ALP:Source:Standard) and generic containers to be used across multiple ALP products are built here
SUSE:ALP:Products:<product_name>:<product_version>[:<product_minor_ve rsion>] This is where the product definitions and patterns live. Each product builds against a SUSE:ALP:Source:<velocity>:Core:<core_version> project Additional packages specific to a product are allowed Ideally packages should be submitted to and linked from :Core: by default (to allow package sharing between products) but exceptions can be made. For openSUSE-only products, such exceptions might be the norm. Containers, VM images, etc specific to a Product are all defined and built here.
SUSE:ALP:Products:<product_name>:<product_version>[:<product_minor_ve rsion>]:Update If a product will be maintained using a SLE/Leap-like maintenance process, then this would be the Update project for such a process.
On 4/19/23 01:19, Richard Brown wrote:
Hello everyone,
Therefore, the current working plan is as follows:
- All SUSE ALP Products will be built in SUSE's Internal Build Service, using sources that originated from openSUSE:Factory - All packages used to build SUSE ALP Products will be copied to openSUSE's Open Build Service without alteration - All SUSE ALP Products will be copied from SUSE's IBS to openSUSE's OBS with the only alterations being the obvious necessary rebranding - Any future changes to the SUSE's ALP development workflow (eg. the possible future introduction of a git-based workflow for submitting changes into IBS/OBS) would be also introduced for any openSUSE ALP Products
This should all sound very familiar because it's very similar in concept to what we already do with Leap Micro
I would like to make the following suggestion to openSUSE on the next steps it could take to extend the above.
Any new openSUSE distribution, such as the ones discussed as https://en.opensuse.org/Portal:16.0 or https://en.opensuse.org/openSUSE:ALP/Workgroups/GrassyKnoll should be built as seperate "Products" using the new ALP way of building things.
The ALP concept should be flexible enough that these openSUSE Products will be able to leverage all the stuff SUSE is doing for SUSE's ALP Products, but then we (community) can add anything we want. If we find it is not flexible enough, then we (SUSE) will work to adapt it to make it possible for the community to build what it wants.
So, if we the community want to build something like old Leap, that should be totally technically feasible. I can certanly imagine the community building something with a stable release cadence and that doesn't use transactional-updates and containers to run everything. If that's the direction we as a community want to go, we should be able to get started soon when the above is in place in OBS.
This is largely what I expected / anticipated / planned for with the Grassy Knoll prototypes, either that or one massive repo with everything and a new way to tell tooling what to look at and what to ignore. My thoughts were if following the "Grassy Knoll" prototype for a new stable release users would probably have the "bedrock" or whatever the main bare metal product repo ends up being called plus an additional openSUSE repo that link in packages from other ALP Products + or in a third repo community packages. So the interesting question then becomes which versions of products do we link to and when and how often do we change these. We probably need more info to make these decisions but we also don't need to right now.
The biggest challenge I forsee would be ensuring we have enough people to maintain all the packages in that 'old fashioned' way of doing things, especially with SUSE going in a different direction...but that has always been an aspect of openSUSE's way of doing things.
This is also my biggest concern, one way that we might be able to help with this is, presuming that ALP containers and flatpaks are built on obs from packages that still have there .spec file, it'd be possible to link them back into openSUSE products. The way they are being used might be different and there might be the occasional bug that doesn't apply to SUSE ALP because of the differences and would need to be community supported but given at the end of the day it shouldn't be much different to tumbleweed or other distros so hopefully those bugs are few and far between. I suspect it'd be the only sustainable way for the community to maintain a full Gnome stack.
SUSE:ALP:Products:<product_name>:<product_version>[:<product_minor_version>]:Update If a product will be maintained using a SLE/Leap-like maintenance process, then this would be the Update project for such a process.
Do you have any info about timeframes / how long support will be? Having access to updates is essential for doing stable distro's i'm guessing it will be different between each product but as a rule of thumb do we know if it will be similar to current SLE / Leap where openSUSE gets standard updates but probably fairly doesn't have access to anything deemed as LTSS? Thanks for all your work on the topic and for a clear detailed email, it makes life much easier to know where we are at. -- 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
Dear Richard, On Tue, 2023-04-18 at 17:49 +0200, Richard Brown wrote:
Hello everyone,
I wanted to write this mail to let everyone know the current status of SUSE's ALP (Adaptable Linux Platform) efforts and hopefully get the ball rolling with openSUSE making use of these efforts.
Many thanks for your mail explaining SUSE's approach to ALP and the consequences thereof for the openSUSE distro and its community at large. Over the last year or so, I have followed the discussions around ALP with great interest and have tried my best to understand, unfortunately in vain, the concrete ways by which this potential evolution of the distro would have an impact on me with respect to two of my most basic use-cases: * As a user: I buy/have a laptop/desktop, if needed reduce the Windows to its deserved 20 GiB disk-space, and install openSUSE on the rest. This is sometimes Tumbleweed, sometimes (very rarely these days, admittedly) Leap. How would my work-flow in downloading and installing the distro — currently involving downloading an iso image, dd-ing it to USB stick, booting up, and enjoying YaST's installer do its thing — change? For that matter, as a user how will this affect my 'zypper this', 'zypper that' (sounds awful, pardon me!) habits? * As a packager, though admittedly not of any core packages, I know how to write basic rpm specfiles, am familiar with the OBS branch, fix, and submit methods, as well as other related stuff that I have learnt over the years (thanks for many gurus in the oS community, of course) that allow me to submit packages to Factory/Leap occasionally. Never built a flatpak in my life, always felt they were some upstream devs' way of getting around downstream distro packagers and shipping to users directly. What will I need to learn and do so that I can keep contributing packages — in whatever guise — when openSUSE ALP starts to take shape? What tooling is there currently or will be in the future to help my transition from an rpm packager to a flatpak (or related) one? Or, is the idea that every oS ALP distro shall come with some upstream Flathub repository subscribed to, making distro packaging, at least for non-core packages (e.g. some science packages like octave) unnecessary? Apologies if this may have been made clear somewhere in this list already previously, but if so please be so kind as to point me towards it. Thanks again and best wishes, -- Atri (@badshah400) Sent from openSUSE Tumbleweed 20230417 on my laptop.
I don’t think there will be changes regarding Tumbleweed and its development. If you are a factory contributor, rpm, OBS should be around the corner and continue to work like they are now. What’s different from now is Leap, which is based on SLE, would be based on ALP in the future. But looking at the above discussion it looks like oS can build an ALP-based Leap which looks similar to the one we are using? If I didn’t get it wrong, ALP core+community packages=future Leap. RPM and OBS wouldn’t disappear in future Leap either if that’s the way. Regards, Charlie ________________________________ From: Atri Bhattacharya <badshah400@opensuse.org> Sent: Thursday, April 20, 2023 2:55 AM To: factory@lists.opensuse.org <factory@lists.opensuse.org> Subject: Re: openSUSE ALP: Current Status & A Starting Point for Future Discussions Dear Richard, On Tue, 2023-04-18 at 17:49 +0200, Richard Brown wrote:
Hello everyone,
I wanted to write this mail to let everyone know the current status of SUSE's ALP (Adaptable Linux Platform) efforts and hopefully get the ball rolling with openSUSE making use of these efforts.
Many thanks for your mail explaining SUSE's approach to ALP and the consequences thereof for the openSUSE distro and its community at large. Over the last year or so, I have followed the discussions around ALP with great interest and have tried my best to understand, unfortunately in vain, the concrete ways by which this potential evolution of the distro would have an impact on me with respect to two of my most basic use-cases: * As a user: I buy/have a laptop/desktop, if needed reduce the Windows to its deserved 20 GiB disk-space, and install openSUSE on the rest. This is sometimes Tumbleweed, sometimes (very rarely these days, admittedly) Leap. How would my work-flow in downloading and installing the distro — currently involving downloading an iso image, dd-ing it to USB stick, booting up, and enjoying YaST's installer do its thing — change? For that matter, as a user how will this affect my 'zypper this', 'zypper that' (sounds awful, pardon me!) habits? * As a packager, though admittedly not of any core packages, I know how to write basic rpm specfiles, am familiar with the OBS branch, fix, and submit methods, as well as other related stuff that I have learnt over the years (thanks for many gurus in the oS community, of course) that allow me to submit packages to Factory/Leap occasionally. Never built a flatpak in my life, always felt they were some upstream devs' way of getting around downstream distro packagers and shipping to users directly. What will I need to learn and do so that I can keep contributing packages — in whatever guise — when openSUSE ALP starts to take shape? What tooling is there currently or will be in the future to help my transition from an rpm packager to a flatpak (or related) one? Or, is the idea that every oS ALP distro shall come with some upstream Flathub repository subscribed to, making distro packaging, at least for non-core packages (e.g. some science packages like octave) unnecessary? Apologies if this may have been made clear somewhere in this list already previously, but if so please be so kind as to point me towards it. Thanks again and best wishes, -- Atri (@badshah400) Sent from openSUSE Tumbleweed 20230417 on my laptop.
How would things like NVIDIA drivers work? Could they easily be updated by a user in an ALP system? -- Roger Oberholtzer
Hi Atri, I think the biggest problem I have answering your questions is that you seem to assume I know the answer to the very question I asked in my original post. The SUSE ALP Products are being built and the code will be made available for openSUSE to reuse. You can get your hands on the prototypes for SUSE's ALP Products to see how they work: https://www.suse.com/c/suse-salp-raises-the-bar-on-confidential-computing/ But, just because this is the direction SUSE is going in, doesn't mean that's all openSUSE has to do. We're getting the codebase, we can decide what we do with it, hence, the core question I ask in my post - what does openSUSE want to build? Without that being answered, I really cant properly answer your below questions, but I'll try and give some ideas.
* As a user: I buy/have a laptop/desktop, if needed reduce the Windows to its deserved 20 GiB disk-space, and install openSUSE on the rest. This is sometimes Tumbleweed, sometimes (very rarely these days, admittedly) Leap. How would my work-flow in downloading and installing the distro — currently involving downloading an iso image, dd-ing it to USB stick, booting up, and enjoying YaST's installer do its thing — change?
The SUSE ALP Prototypes all use Agama (formerly D-Installer) as their installer, not YaST. One nice thing with Agama is that you typically download a single ISO and that ISO offers _all_ the related 'Products' So, assuming openSUSE's ALP offerings include all of SUSE's ALP Products AND one (or more) community build offerings, I imagine we won't have separate installation ISO's for everything, and have one openSUSE ALP Installer ISO that offers Bedrock, Micro, and whatever the community builds. But, that's a whole bunch of assumptions with that vision - does openSUSE build anything based on ALP? would it make sense to offer alongside the openSUSE versions of SUSE's ALP Server/Cloud-Native products? Do people really want to build an old fashioned YaST installer and are willing to do all that work? I dunno, and so I cant really say your question is answered.
For that matter, as a user how will this affect my 'zypper this', 'zypper that' (sounds awful, pardon me!) habits?
No clue - if openSUSE builds something transactional, then those 'zypper this' habits might become 'transactional-update this' and 'podman this' habits. If openSUSE builds a Desktop that is very flatpak centric, then those 'zypper this' habits might become 'flatpak this' (or picking nice stuff in GNOME Software's UI) habits If openSUSE builds something old fashioned, the 'zypper this' habits would say And maybe someone will develop something entirely different I've got no idea until people answer the core question of my post..what do we want to build?
* As a packager, though admittedly not of any core packages, I know how to write basic rpm specfiles, am familiar with the OBS branch, fix, and submit methods, as well as other related stuff that I have learnt over the years (thanks for many gurus in the oS community, of course) that allow me to submit packages to Factory/Leap occasionally. Never built a flatpak in my life, always felt they were some upstream devs' way of getting around downstream distro packagers and shipping to users directly. What will I need to learn and do so that I can keep contributing packages — in whatever guise — when openSUSE ALP starts to take shape? What tooling is there currently or will be in the future to help my transition from an rpm packager to a flatpak (or related) one? Or, is the idea that every oS ALP distro shall come with some upstream Flathub repository subscribed to, making distro packaging, at least for non-core packages (e.g. some science packages like octave) unnecessary?
Again, I can't speculate about what you'll need to do different when I'm also not able to speculate about what openSUSE might decide to build atop of ALP. The door is wide open for openSUSE to define it's future, I think people need to think more about _what_ that needs to look like. We can figure out the _how_ as we do it. -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
On 4/20/23 18:11, Richard Brown wrote:
For that matter, as a user how will this affect my 'zypper this', 'zypper that' (sounds awful, pardon me!) habits?
No clue - if openSUSE builds something transactional, then those 'zypper this' habits might become 'transactional-update this' and 'podman this' habits.
If openSUSE builds a Desktop that is very flatpak centric, then those 'zypper this' habits might become 'flatpak this' (or picking nice stuff in GNOME Software's UI) habits
If openSUSE builds something old fashioned, the 'zypper this' habits would say
And maybe someone will develop something entirely different
I've got no idea until people answer the core question of my post..what do we want to build?
If we do end up in a hybrid world with a mix of rpm and flatpak it'd be great if someone wrote an abstraction layer so both could be updated at the same time and you could just run "foo install firefox" and get firefox from the right location depending on the product your using. Again while I think this would be ideal I haven't needed it enough to write anything myself but it would be a great hackweek idea for next time. On the other hand to date the number of podman containers I personally use is low enough that I normally just write a systemd service for each and am done with it. -- 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 2023-04-20 13:10, Simon Lees wrote:
On 4/20/23 18:11, Richard Brown wrote:
I've got no idea until people answer the core question of my post..what do we want to build?
If we do end up in a hybrid world with a mix of rpm and flatpak it'd be great if someone wrote an abstraction layer so both could be updated at the same time and you could just run "foo install firefox" and get firefox from the right location depending on the product your using. Again while I think this would be ideal I haven't needed it enough to write anything myself but it would be a great hackweek idea for next time.
On the other hand to date the number of podman containers I personally use is low enough that I normally just write a systemd service for each and am done with it.
Well, as you can see in the GNOME MicroOS Desktop, I have a strong opinion on the best way of handling a 'hybrid' world where both rpms and flatpaks are key parts of the Desktop. There we have nice graphical tools for handling the flatpaks, like GNOME Software. No typing anything, just pressing pretty buttons. And, for handling the rpms, people shouldn't need to mess around with that and the ideal is to have all the updates entirely automated with just notifications reminding folk to reboot from time to time. And for those people who really want to tinker, transactional-update is no more egregious than using zypper. I think this vision works quite well, far less terminal tinkering than a traditional system, and even those who do want/need to mess with the system RPMs should find themselves needing to do so far less often. But given the MicroOS Desktop takes care of this pretty damn well IMNSHO I only see a benefit of doing it again based on ALP if people really either have a desire for the ALP base system instead of a Tumbleweed one, or, if they wish to use the opportunity of taking that core concept of the MicroOS Desktop but maybe being a little less strict on the polish than the MicroOS Desktop community are being. The door is certainly open if people want to go down that road..now would be as good an opportunity as any to try it out -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
On 4/21/23 20:45, Richard Brown wrote:
On 2023-04-20 13:10, Simon Lees wrote:
On 4/20/23 18:11, Richard Brown wrote:
I've got no idea until people answer the core question of my post..what do we want to build?
If we do end up in a hybrid world with a mix of rpm and flatpak it'd be great if someone wrote an abstraction layer so both could be updated at the same time and you could just run "foo install firefox" and get firefox from the right location depending on the product your using. Again while I think this would be ideal I haven't needed it enough to write anything myself but it would be a great hackweek idea for next time.
On the other hand to date the number of podman containers I personally use is low enough that I normally just write a systemd service for each and am done with it.
Well, as you can see in the GNOME MicroOS Desktop, I have a strong opinion on the best way of handling a 'hybrid' world where both rpms and flatpaks are key parts of the Desktop.
There we have nice graphical tools for handling the flatpaks, like GNOME Software. No typing anything, just pressing pretty buttons.
Does this also handle rpm's? I am generally unfamiliar with it as an openSUSE user who has access to yast and doesn't use Gnome (other then in lightning talks to show its useability issues :-P) i'm not that familiar with it. So would it be a better base for a hybrid solution then yast? and would upstream accept contributions? One other thing we found with Grassy Knoll is the dependency stack for anything Gnome related becomes very large very quickly and how / what we get from SUSE is still pretty unclear at this point. Having said that GDM has similar issues and i'd like to solve them there because its significantly better then lightdm in many applications. -- 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 Wed, Apr 26, 2023 at 4:43 AM Simon Lees <sflees@suse.de> wrote:
On 4/21/23 20:45, Richard Brown wrote:
On 2023-04-20 13:10, Simon Lees wrote:
On 4/20/23 18:11, Richard Brown wrote:
I've got no idea until people answer the core question of my post..what do we want to build?
If we do end up in a hybrid world with a mix of rpm and flatpak it'd be great if someone wrote an abstraction layer so both could be updated at the same time and you could just run "foo install firefox" and get firefox from the right location depending on the product your using. Again while I think this would be ideal I haven't needed it enough to write anything myself but it would be a great hackweek idea for next time.
On the other hand to date the number of podman containers I personally use is low enough that I normally just write a systemd service for each and am done with it.
Well, as you can see in the GNOME MicroOS Desktop, I have a strong opinion on the best way of handling a 'hybrid' world where both rpms and flatpaks are key parts of the Desktop.
There we have nice graphical tools for handling the flatpaks, like GNOME Software. No typing anything, just pressing pretty buttons.
Does this also handle rpm's? I am generally unfamiliar with it as an
Yes, GNOME Software handles normal RPMs. Actually it handles anything PackageKit handles as it is more or less just a frontend to PackageKit. What GNOME Software likely does not support is transactional-update and this support must go into PackageKit. And this will conflict with offline updates as done currently, it is an entirely different mode of operation.
On 2023-04-26 03:43, Simon Lees wrote:
On 4/21/23 20:45, Richard Brown wrote:
On 2023-04-20 13:10, Simon Lees wrote:
There we have nice graphical tools for handling the flatpaks, like GNOME Software. No typing anything, just pressing pretty buttons.
Does this also handle rpm's? I am generally unfamiliar with it as an openSUSE user who has access to yast and doesn't use Gnome (other then in lightning talks to show its useability issues :-P) i'm not that familiar with it.
In the MicroOS Desktop we have removed all rpm handling from GNOME Software - This is one of the reasons it runs liked greased lightning now :) However before then, we did a number of experiments, especially around using dnf/microdnf (which has a much more robust packagekit backend) and extending that backend to support Transactional Updates by adding libtukit support. This fell apart though, mostly because libtukit (quite rightly) only provides the generic distribution-neutral functionality to do transactional-updates. Distro specific logic, like handing the openSUSE way of doing kernel updates and bootloader/initrd generation isn't there at all. That meant that it 'worked'..until you had a kernel update and then your system stopped booting. Not exactly the level of reliability we wanted ;) And no one ever got around into introducing like this logic into dnf/microdnf, so we had to drop that effort and I made the call to rip out all the rpm handling entirely
So would it be a better base for a hybrid solution then yast? and would upstream accept contributions? One other thing we found with Grassy Knoll is the dependency stack for anything Gnome related becomes very large very quickly and how / what we get from SUSE is still pretty unclear at this point. Having said that GDM has similar issues and i'd like to solve them there because its significantly better then lightdm in many applications.
Well, despite giving the idea of 'hybrid' graphical package management a chance, in the context of the MicroOS Desktop I actually LOVE where we've ended up. In that OS, we WANT to encourage people to use Flatpaks as a first class citizen for graphical apps. For commandline apps or graphical apps that aren't flatpaks, we have rpms installed using regular ol' zypper inside distroboxes. Messing around with packages in the host OS is really a last resort if the above two don't work, and in that context making people use transactional-update is just fine. If you want my opinion, there is no better solution for a transactional, read-only root Desktop. If people disagree with my world-view though and really want to do something in this area, the best way forward would be resurrecting the dnf/microdnf-libtukit-packagekit integrations and extending them so they're feature complete with transactional-update. -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
On 4/26/23 18:31, Richard Brown wrote:
On 2023-04-26 03:43, Simon Lees wrote:
On 4/21/23 20:45, Richard Brown wrote:
On 2023-04-20 13:10, Simon Lees wrote:
There we have nice graphical tools for handling the flatpaks, like GNOME Software. No typing anything, just pressing pretty buttons.
Does this also handle rpm's? I am generally unfamiliar with it as an openSUSE user who has access to yast and doesn't use Gnome (other then in lightning talks to show its useability issues :-P) i'm not that familiar with it.
In the MicroOS Desktop we have removed all rpm handling from GNOME Software - This is one of the reasons it runs liked greased lightning now :)
However before then, we did a number of experiments, especially around using dnf/microdnf (which has a much more robust packagekit backend) and extending that backend to support Transactional Updates by adding libtukit support.
This fell apart though, mostly because libtukit (quite rightly) only provides the generic distribution-neutral functionality to do transactional-updates. Distro specific logic, like handing the openSUSE way of doing kernel updates and bootloader/initrd generation isn't there at all.
Was this related just to Transactional Updates or would a system otherwise updating with a more traditional zypper / dnf also have these issues? If not then we could drop those no rpm patches for products that don't use transactional updates.
So would it be a better base for a hybrid solution then yast? and would upstream accept contributions? One other thing we found with Grassy Knoll is the dependency stack for anything Gnome related becomes very large very quickly and how / what we get from SUSE is still pretty unclear at this point. Having said that GDM has similar issues and i'd like to solve them there because its significantly better then lightdm in many applications.
Well, despite giving the idea of 'hybrid' graphical package management a chance, in the context of the MicroOS Desktop I actually LOVE where we've ended up.
In that OS, we WANT to encourage people to use Flatpaks as a first class citizen for graphical apps. For commandline apps or graphical apps that aren't flatpaks, we have rpms installed using regular ol' zypper inside distroboxes.
Messing around with packages in the host OS is really a last resort if the above two don't work, and in that context making people use transactional-update is just fine.
If you want my opinion, there is no better solution for a transactional, read-only root Desktop.
If people disagree with my world-view though and really want to do something in this area, the best way forward would be resurrecting the dnf/microdnf-libtukit-packagekit integrations and extending them so they're feature complete with transactional-update.
At this stage I know of maintainers who are happy to submit there Tumbleweed packages to a "Leap 16" because in many cases this isn't significant effort but don't really want to go to the effort of learning to make flatpacks however that ends up happening. So from that perspective having both might be the best solution. Or alternatively if its a relevantly simple to rebuild whatever flatpak's SUSE creates for there desktop as rpm's we could consider rpm only to be the official way for those packages even though 3rd party rpm's are becoming more popular and may help fill some gaps in the package list if the number of maintainers is less. So atm hybrid is probably going to wind up being the best solution. -- 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 Wed, Apr 26, 2023 at 5:02 AM Richard Brown <rbrown@suse.de> wrote:
On 2023-04-26 03:43, Simon Lees wrote:
On 4/21/23 20:45, Richard Brown wrote:
On 2023-04-20 13:10, Simon Lees wrote:
There we have nice graphical tools for handling the flatpaks, like GNOME Software. No typing anything, just pressing pretty buttons.
Does this also handle rpm's? I am generally unfamiliar with it as an openSUSE user who has access to yast and doesn't use Gnome (other then in lightning talks to show its useability issues :-P) i'm not that familiar with it.
In the MicroOS Desktop we have removed all rpm handling from GNOME Software - This is one of the reasons it runs liked greased lightning now :)
However before then, we did a number of experiments, especially around using dnf/microdnf (which has a much more robust packagekit backend) and extending that backend to support Transactional Updates by adding libtukit support.
This fell apart though, mostly because libtukit (quite rightly) only provides the generic distribution-neutral functionality to do transactional-updates. Distro specific logic, like handing the openSUSE way of doing kernel updates and bootloader/initrd generation isn't there at all.
That meant that it 'worked'..until you had a kernel update and then your system stopped booting. Not exactly the level of reliability we wanted ;)
And no one ever got around into introducing like this logic into dnf/microdnf, so we had to drop that effort and I made the call to rip out all the rpm handling entirely
So would it be a better base for a hybrid solution then yast? and would upstream accept contributions? One other thing we found with Grassy Knoll is the dependency stack for anything Gnome related becomes very large very quickly and how / what we get from SUSE is still pretty unclear at this point. Having said that GDM has similar issues and i'd like to solve them there because its significantly better then lightdm in many applications.
Well, despite giving the idea of 'hybrid' graphical package management a chance, in the context of the MicroOS Desktop I actually LOVE where we've ended up.
In that OS, we WANT to encourage people to use Flatpaks as a first class citizen for graphical apps. For commandline apps or graphical apps that aren't flatpaks, we have rpms installed using regular ol' zypper inside distroboxes.
Messing around with packages in the host OS is really a last resort if the above two don't work, and in that context making people use transactional-update is just fine.
If you want my opinion, there is no better solution for a transactional, read-only root Desktop.
If people disagree with my world-view though and really want to do something in this area, the best way forward would be resurrecting the dnf/microdnf-libtukit-packagekit integrations and extending them so they're feature complete with transactional-update.
And for what it's worth, the logic for that is all centered in a libdnf plugin: https://code.opensuse.org/microos/libdnf-plugin-txnupd Contributions are certainly welcome! :) -- 真実はいつも一つ！/ Always, there's only one truth!
Hi Richard, thank you for this detailed write-up! (more inline below) Richard Brown <rbrown@suse.de> writes: *snip*
Therefore, the current working plan is as follows:
- All SUSE ALP Products will be built in SUSE's Internal Build Service, using sources that originated from openSUSE:Factory - All packages used to build SUSE ALP Products will be copied to openSUSE's Open Build Service without alteration - All SUSE ALP Products will be copied from SUSE's IBS to openSUSE's OBS with the only alterations being the obvious necessary rebranding - Any future changes to the SUSE's ALP development workflow (eg. the possible future introduction of a git-based workflow for submitting changes into IBS/OBS) would be also introduced for any openSUSE ALP Products
Would you know where the primary development will take place? OBS or IBS? If it is moved to IBS, then that will make community contributions quite challenging, as they already are with Leap at the moment. Would it be an option that development happens on OBS and the sources are mirrored/copied/submitted to IBS? That's our current workflow for SLE-BCI and I'd say it works reasonably well, albeit I am not sure if it would scale. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On 4/20/23 16:31, Dan Čermák wrote:
Hi Richard,
thank you for this detailed write-up!
(more inline below)
Richard Brown <rbrown@suse.de> writes:
*snip*
Therefore, the current working plan is as follows:
- All SUSE ALP Products will be built in SUSE's Internal Build Service, using sources that originated from openSUSE:Factory - All packages used to build SUSE ALP Products will be copied to openSUSE's Open Build Service without alteration - All SUSE ALP Products will be copied from SUSE's IBS to openSUSE's OBS with the only alterations being the obvious necessary rebranding - Any future changes to the SUSE's ALP development workflow (eg. the possible future introduction of a git-based workflow for submitting changes into IBS/OBS) would be also introduced for any openSUSE ALP Products
Would you know where the primary development will take place? OBS or IBS?
If it is moved to IBS, then that will make community contributions quite challenging, as they already are with Leap at the moment. Would it be an option that development happens on OBS and the sources are mirrored/copied/submitted to IBS? That's our current workflow for SLE-BCI and I'd say it works reasonably well, albeit I am not sure if it would scale.
My understanding of Common Critera Cert is that all submissions need to be reviewed twice internally, ie by the package maintainer and the SUSE review team. So I think probably the best you could do is add some mechanism where by a community member could somehow create a SR that gets forwarded into IBS so that the maintainer and other relevant people could review it there before inclusion. Which would likely be significant changes in IBS/OBS. But maybe I got those requirements wrong its been a long time since I discussed them with people. Given that we are also looking at the git based packaging workflow it might make more sense to just wind up with a working review system for the community there. -- 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
Simon Lees <sflees@suse.de> writes:
On 4/20/23 16:31, Dan Čermák wrote:
Hi Richard,
thank you for this detailed write-up!
(more inline below)
Richard Brown <rbrown@suse.de> writes:
*snip*
Therefore, the current working plan is as follows:
- All SUSE ALP Products will be built in SUSE's Internal Build Service, using sources that originated from openSUSE:Factory - All packages used to build SUSE ALP Products will be copied to openSUSE's Open Build Service without alteration - All SUSE ALP Products will be copied from SUSE's IBS to openSUSE's OBS with the only alterations being the obvious necessary rebranding - Any future changes to the SUSE's ALP development workflow (eg. the possible future introduction of a git-based workflow for submitting changes into IBS/OBS) would be also introduced for any openSUSE ALP Products
Would you know where the primary development will take place? OBS or IBS?
If it is moved to IBS, then that will make community contributions quite challenging, as they already are with Leap at the moment. Would it be an option that development happens on OBS and the sources are mirrored/copied/submitted to IBS? That's our current workflow for SLE-BCI and I'd say it works reasonably well, albeit I am not sure if it would scale.
My understanding of Common Critera Cert is that all submissions need to be reviewed twice internally, ie by the package maintainer and the SUSE review team. So I think probably the best you could do is add some mechanism where by a community member could somehow create a SR that gets forwarded into IBS so that the maintainer and other relevant people could review it there before inclusion. Which would likely be significant changes in IBS/OBS. But maybe I got those requirements wrong its been a long time since I discussed them with people.
That's how it's supposed to work currently with submissions to Leap: your SR gets mirrored internally on IBS. Unfortunately that means that if the submission needs modifications, then things get very complicated and usually involve manual steps (someone from SUSE forwarding the feedback to the community contributor, starting a lengthy back-and-forth). I'd very much prefer if we do not repeat this process for ALP at all.
Given that we are also looking at the git based packaging workflow it might make more sense to just wind up with a working review system for the community there.
Git will not fundamentally change that community contributors don't have access to the SUSE internal infrastructure. What git might help with is commits having hashes and being signed, which would allow for an automated cherry-pick/clone. But it's still not a trivial thing to solve. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
Hi Dan, On 2023-04-20 09:01, Dan Čermák wrote:
Hi Richard,
thank you for this detailed write-up!
(more inline below)
Richard Brown <rbrown@suse.de> writes:
*snip*
Therefore, the current working plan is as follows:
- All SUSE ALP Products will be built in SUSE's Internal Build Service, using sources that originated from openSUSE:Factory - All packages used to build SUSE ALP Products will be copied to openSUSE's Open Build Service without alteration - All SUSE ALP Products will be copied from SUSE's IBS to openSUSE's OBS with the only alterations being the obvious necessary rebranding - Any future changes to the SUSE's ALP development workflow (eg. the possible future introduction of a git-based workflow for submitting changes into IBS/OBS) would be also introduced for any openSUSE ALP Products
Would you know where the primary development will take place? OBS or IBS?
If it is moved to IBS, then that will make community contributions quite challenging, as they already are with Leap at the moment. Would it be an option that development happens on OBS and the sources are mirrored/copied/submitted to IBS? That's our current workflow for SLE-BCI and I'd say it works reasonably well, albeit I am not sure if it would scale.
For the SUSE ALP Products and the Packages/Containers/Stuff making up those SUSE ALP Products, the primary development will take place in IBS. This is mandatory for the certifications that SUSE require for ALP. Development cannot happen in OBS. There will be no path for community contribution to that part of the SUSE developed ALP stuff in the short term. After discussing with Lubos it is pretty clear to me that the Leap/SLE-BCI style mirroring/copying of submissions absolutely will not scale. Any proper solution isn't just a technical challenge of getting OBS and IBS to copy/mirror submissions and keep them in sync, but also process changes (possibly to both openSUSE and SUSE) to ensure everything is done in a way that be certified when in SUSE's ALP Products. Let me be absolutely clear though, this is NOT ideal, we don't want to keep it this way, I just don't see a plausible solution that can be put in place in time that wouldn't disrupt SUSE's plans for making ALP Products AND make it harder/add more delays to openSUSE being able to make use of SUSE's ALP stuff. However, I do not see this is as the end of the world, because after all, ALP is meant to be adaptable. openSUSE will be able to make it's own ALP Products based on the SUSE ALP stuff. For those openSUSE ALP Products, the primary development will take place in OBS, and have a typical openSUSE-style contribution path. This is playing to the benefits we have with the ALP design, and I expect openSUSE will do an awesome job pushing the 'Adaptability' aspect of ALP to it's limit. The question really though is, given the above, what does the openSUSE community want to build? (yes..I know, I'm repeating the main question from my original post..but we really do need to have some discussions on that else the answer will be 'nothing') -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
On 2023-04-20 10:27, Richard Brown wrote:
The question really though is, given the above, what does the openSUSE community want to build?
If I am allowed to chime in, I would say "nothing". I see ALP more about innovation in the process of building a distribution instead of a technical asset that can be repurposed to build some derivative. So instead of building something on top of ALP, I would take those very valuable improvement in the process and try to integrate naturally in openSUSE. For example: * Embrace and improve the git-based development model. * Rethink the ring-0,1 and devel projects based on the layout that ALP is experimenting. Maybe a reformulation can help to separate better the realm of bootstrap, core and pool for packages. * Redefine MicroOS and MicroOS Desktop on top of this model, so I can separate good MicroOS packages (packages that behave well in transactional OS) from other that needs to be adapted * Use the new installation methods like d-installer / agama For me, having an openSUSE ALP should be less useful, unless I am in a position where I expect to migrate later to SUSE ALP looking for support (also a valuable feature, but I would expect in this case that is SUSE who define this openSUSE ALP, instead the project itself)
On 2023-04-20 11:17, aplanas wrote:
On 2023-04-20 10:27, Richard Brown wrote:
The question really though is, given the above, what does the openSUSE community want to build?
If I am allowed to chime in, I would say "nothing".
You most certainly can chime in. "Nothing" is certainly a valid option.
I see ALP more about innovation in the process of building a distribution instead of a technical asset that can be repurposed to build some derivative.
So instead of building something on top of ALP, I would take those very valuable improvement in the process and try to integrate naturally in openSUSE.
For example:
* Embrace and improve the git-based development model.
* Rethink the ring-0,1 and devel projects based on the layout that ALP is experimenting. Maybe a reformulation can help to separate better the realm of bootstrap, core and pool for packages.
* Redefine MicroOS and MicroOS Desktop on top of this model, so I can separate good MicroOS packages (packages that behave well in transactional OS) from other that needs to be adapted
* Use the new installation methods like d-installer / agama
I agree the above ideas are really interesting and I feel it's inevitable that we will explore them. I fully intend to drive initiatives like those you describe above. But, the question is 'when' If your suggestion of building "nothing" from the SUSE ALP products gains consensus, then I won't have to spend my time helping getting whatever openSUSE wants to build off the ground. Else your suggestions will probably have to wait till later in the year/next year before I can get around to them :) -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
On 4/20/23 17:57, Richard Brown wrote:
The question really though is, given the above, what does the openSUSE community want to build? (yes..I know, I'm repeating the main question from my original post..but we really do need to have some discussions on that else the answer will be 'nothing')
Well i'm probably the one person who's answered this before but i'll go again to get us rolling. I have a desktop that doubles as a KVM Server that I use for testing desktop related packages and some other developments. Tumbleweed isn't a great solution for it because rebooting becomes painful. This combined with feedback i've read from others across various lists leads me to wanting to build the following. * Something that can run one of the lighter X11 based desktops XFCE / Enlightenment etc, without the need for containers and preferably with as many apps as practical delivered as RPM's. I still have apps that require X11. * Something that is Leap / Tumbleweed like, ie read / write filesystems and transactional updates, that will provide some form of possibly limited migration path (Migrating a desktop system with packages still provided in openSUSE ALP should work, although some services may need more migration action and obviously if there's no ALP replacement for software it wont. Having said that Migration is more of a side effect of the fact that I have a bunch of desktop related packages that I don't really feel like putting in the work to migrate to working with transactional updates. From the research I did with "Grassy Knoll" during hackweek the amount of work needed to implement this to meet my personal needs would be sustainable although many of these packages are reasonably low maintenance. The research also suggests that this will probably also be enough of a platform that it should be pretty easy for other people to start adding there own packages. One thing we did find though particularly for XFCE alot of things will depend on where SUSE lands with GTK etc, at worst it might need to be bought in from tumbleweed. But we probably still need more info for this. For now i'd put off doing much more work until after 15.5 was released and more questions were answered, although many of those questions have now been answered. On a completely different note i'd love to see a product along the lines of Raspbian that has a focus on raspberry pi and other boards for smaller embedded / home automation and various other things etc. How much time I have to work on that atm is another question. But in the future I have a robot that could use a new OS. Cheers -- 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
Dne čtvrtek 20. dubna 2023 12:48:06 CEST, Simon Lees napsal(a):
On 4/20/23 17:57, Richard Brown wrote:
The question really though is, given the above, what does the openSUSE community want to build? (yes..I know, I'm repeating the main question from my original post..but we really do need to have some discussions on that else the answer will be 'nothing')
Well i'm probably the one person who's answered this before but i'll go again to get us rolling. I have a desktop that doubles as a KVM Server that I use for testing desktop related packages and some other developments. Tumbleweed isn't a great solution for it because rebooting becomes painful. This combined with feedback i've read from others across various lists leads me to wanting to build the following. * Something that can run one of the lighter X11 based desktops XFCE / Enlightenment etc, without the need for containers and preferably with as many apps as practical delivered as RPM's. I still have apps that require X11. * Something that is Leap / Tumbleweed like, ie read / write filesystems and transactional updates, that will provide some form of possibly limited migration path (Migrating a desktop system with packages still provided in openSUSE ALP should work, although some services may need more migration action and obviously if there's no ALP replacement for software it wont. Having said that Migration is more of a side effect of the fact that I have a bunch of desktop related packages that I don't really feel like putting in the work to migrate to working with transactional updates. From the research I did with "Grassy Knoll" during hackweek the amount of work needed to implement this to meet my personal needs would be sustainable although many of these packages are reasonably low maintenance. The research also suggests that this will probably also be enough of a platform that it should be pretty easy for other people to start adding there own packages. One thing we did find though particularly for XFCE alot of things will depend on where SUSE lands with GTK etc, at worst it might need to be bought in from tumbleweed. But we probably still need more info for this. For now i'd put off doing much more work until after 15.5 was released and more questions were answered, although many of those questions have now been answered. On a completely different note i'd love to see a product along the lines of Raspbian that has a focus on raspberry pi and other boards for smaller embedded / home automation and various other things etc. How much time I have to work on that atm is another question. But in the future I have a robot that could use a new OS.
I'm sorry, I still bit fail to understand how ALP will look like, but it probably doesn't matter now. :-) I'd just like to briefly describe my user cases as I wonder how they could be covered by ALP. 1) On my machines I use Tumbleweed. I absolutely love it. Newest versions, everything working. As I install various packages very frequently (typically when I need to compile new scientific SW), need of reboot after every install would be absolutely no-go. Also I use KDE, GNOME never ever. Sorry. :-) 2) When my colleagues ask me to install Linux for them (needed for bioinformatics), I install them Leap. It's rock stable, doesn't change much among minor versions, easy to use, I can easily create RPM packages for SW we need for us, etc. Again, need of reboot after every install would be extremely annoying. My colleagues use mostly KDE, sometimes XFCE. 3) On servers I use Leap. There I don't care much if there would be something MicroOS-like or so. 4) "Office desktop". E.g. my wife has already pretty old notebook (low performance) for working with LibrOffice, web apps, videocalls etc. I don't remember when last time she needed to install something there, so reboot after install isn't any problem. I'm rather bit afraid about performance. As containers add extra layer, I don't believe it's without impact on performance. I personally am not fan of various containers, I don't see any benefit in it, at least for my usages, but OK, if this is trend with good technical reasons I don't know/get, fine. One of my reasons why I'm using openSUSE is OBS and very easy and straightforward way of creating RPM packages. If the same spec file could generate also whatever container needed, it'd be perfect. I do bit emphasize need of reboot (to my understanding it's inevitable side effect of transactional updates) as it has huge impact to convenience of work, so I'd like to avoid it. In any case I'm looking forward what ALP will bring. :-) -- Vojtěch Zeisek https://trapa.cz/ Komunita openSUSE GNU/Linuxu Community of the openSUSE GNU/Linux https://www.opensuse.org/
On 2023-04-20 13:33, Vojtěch Zeisek wrote:
Dne čtvrtek 20. dubna 2023 12:48:06 CEST, Simon Lees napsal(a):
On 4/20/23 17:57, Richard Brown wrote:
The question really though is, given the above, what does the openSUSE community want to build? (yes..I know, I'm repeating the main question from my original post..but we really do need to have some discussions on that else the answer will be 'nothing')
I'm sorry, I still bit fail to understand how ALP will look like, but it probably doesn't matter now. :-) I'd just like to briefly describe my user cases as I wonder how they could be covered by ALP.
You can see how SUSE's ALP Products currently look like by downloading any of the published prototypes: https://www.suse.com/c/suse-salp-raises-the-bar-on-confidential-computing/
1) On my machines I use Tumbleweed. I absolutely love it. Newest versions, everything working. As I install various packages very frequently (typically when I need to compile new scientific SW), need of reboot after every install would be absolutely no-go. Also I use KDE, GNOME never ever. Sorry. :-)
Ok..but, we're not changing anything with Tumbleweed, so, why are you bringing this up?
2) When my colleagues ask me to install Linux for them (needed for bioinformatics), I install them Leap. It's rock stable, doesn't change much among minor versions, easy to use, I can easily create RPM packages for SW we need for us, etc. Again, need of reboot after every install would be extremely annoying. My colleagues use mostly KDE, sometimes XFCE.
4) "Office desktop". E.g. my wife has already pretty old notebook (low performance) for working with LibrOffice, web apps, videocalls etc. I don't remember when last time she needed to install something there, so reboot after install isn't any problem. I'm rather bit afraid about performance. As containers add extra layer, I don't believe it's without impact on performance.
Ok, so, are you volunteering to build an ALP based KDE/XFCE Desktop? Or an 'office desktop' as you define here? Or Both? Let's keep this conversation on the topic of what people are willing to actually step up and build. Wishes and dreams are all fine, but we really need to know what people are willing to help build in reality as opposed to an ideal dream world. Alberto's and Simon's mails are a great example of what I'd like to see in this thread, with clear concrete visions of what they are willing to help us look into next. -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
On Thu, 2023-04-20 at 13:41 +0200, Richard Brown wrote:
Let's keep this conversation on the topic of what people are willing to actually step up and build. Wishes and dreams are all fine, but we really need to know what people are willing to help build in reality as opposed to an ideal dream world.
The question is, in it's current state where ALP is basically developed in IBS, is there even a way how people CAN contribute? I'm saying this as someone who maintains a couple of Tumbleweed packages, and despite several attempts to bring some of them to Leap I gave up at some point because it was basically impossible. I'm saying this to ensure we're not repeating the same unfortunate situation for ALP, where the statement that the community should take care of this matter, is met with an impenetrable process that does not allow easily for contributions outside of the corporate walls (hyperbolism intentionally for drama). It is easy to contribute to Tumbleweed because it comes before corporate requirements (I believe). It's almost impossible to do the same for Leap, where compliance and convergence (aka closing the Leap gap) is a main goal. I truly hope for ALP we can find a way, to make community contributions as simple as it is for Tumbleweed, despite it's prime resources being located in IBS (with all attached requirements). Best, Felix
Hi Felix, On 2023-04-20 17:17, Felix Niederwanger wrote:
The question is, in it's current state where ALP is basically developed in IBS, is there even a way how people CAN contribute?
I'm saying this as someone who maintains a couple of Tumbleweed packages, and despite several attempts to bring some of them to Leap I gave up at some point because it was basically impossible.
As I tried to explain in my original mail, ALP is built really very differently than everything we’ve built to date. I’ll try and restate it here to help explain why I don’t share your concern. Unlike TW, Leap and SLE, ALP doesn’t have a single monolithic codebase in which all packages must go and all products must come out from. Instead it’s built, kinda in layers I’ll give simplified examples ALP:Source:Standard - this is where all the source packages of the “Standard” ALP code “track” will exist. None of the packages will be built here. Some day there may be other code tracks ALP:Source:Rolling for example might be what Tumbleweed evolves into some day So.. that’s the first layer ALP:Products:FOO is the next layer. This is where packages are actually built, where the products are actually built, ISOs, etc ALP:Products:FOO May inherit some packages from ALP:Source:Standard It may inherit packages from other ALP:Source:BAR tracks once they exist And ALP:Products:FOO may also include packages/containers/flatpaks/whatever that only exist in that product So, when it comes to contribution Right now, all the ALP stuff we will be getting from SUSE Will be coming from IBS and I see no good way to create a contribution path to them (FOR NOW) That is the projects we currently know as: SUSE:ALP:Source:Standard and the SUSE:ALP:Products:Bedrock and Micro We’re gonna have openSUSE copies of these, but no good way of contributing back so, for the short term at least, you can think of those ALP Products like ALPs CentOS - a community rebuild of a commercial distro But, this whole conversation is about what OTHER ALP Products does openSUSE want to make? We can do whatever we want in our own openSUSE:ALP:Products namespace And in that namespace, for those products, contribution will be no problem, as we will be doing something very different in scope from SUSEs products Does this clear up your question? —- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
Richard Brown <rbrown@suse.de> writes:
Hi Felix, *snip* So, when it comes to contribution
Right now, all the ALP stuff we will be getting from SUSE Will be coming from IBS and I see no good way to create a contribution path to them (FOR NOW)
I do not intend to shoot the messenger, so please don't take this personally, but Imho it's quite the mistake and regression from the promised way ALP would be developed. Could a path to contribution that is not terrible be please made a high priority? Otherwise, ALP is really not that much different from SLE (at the moment at least). Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
On 2023-04-21 08:18, Dan Čermák wrote:
Richard Brown <rbrown@suse.de> writes:
Hi Felix, *snip* So, when it comes to contribution
Right now, all the ALP stuff we will be getting from SUSE Will be coming from IBS and I see no good way to create a contribution path to them (FOR NOW)
I do not intend to shoot the messenger, so please don't take this personally, but Imho it's quite the mistake and regression from the promised way ALP would be developed.
Could a path to contribution that is not terrible be please made a high priority? Otherwise, ALP is really not that much different from SLE (at the moment at least).
Given the constraints in play, I don't think it would make sense to make it a higher priority than it already is SUSE is very focused on getting their ALP products out by the end of the year openSUSE hasn't even decided what it wants to build based on ALP Forcing SUSE to change how they develop ALP will delay their efforts, while not give openSUSE anything in the short term - it's not like we're even in a position to make use of that contribution path if we had it. We can do whatever we want in our openSUSE ALP Products meanwhile, and then we can consolidate, correct, and improve the situation afterwards. We all agree it's not ideal, but, it's how it is. -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
On Friday 2023-04-21 11:55, Richard Brown wrote:
SUSE is very focused on getting their ALP products out by the end of the year. openSUSE hasn't even decided what it wants to build based on ALP.
We can do whatever we want in our openSUSE ALP Products meanwhile, and then we can consolidate, correct, and improve the situation afterwards.
I'm with you on that. Worst that happens is that more people will use Tumbleweed :D
On 21.04.23 11:59, Jan Engelhardt wrote:
On Friday 2023-04-21 11:55, Richard Brown wrote: >> We can do whatever we want in our openSUSE ALP Products meanwhile,
and then we
can consolidate, correct, and improve the situation afterwards.
I'm with you on that. Worst that happens is that more people will use Tumbleweed :D
Or Fedora, RockyLinux, Ubuntu, whatever. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Hello Richard, in short: Yes this addresses my point and was probably the most elaborate description of ALP that I stumbled across recently ;-) The TLDR of what I wanted to highlight was summarized by you spot on:
Right now, all the ALP stuff we will be getting from SUSE Will be coming from IBS and I see no good way to create a contribution path to them (FOR NOW).
(Dan also put the finger on the wound ... ) And I like to highlight also the addition of
We can do whatever we want in our own openSUSE:ALP:Products namespace
which might indicate a possible contribution path. This is still a little bit unsatisfactory, as future products developed atop of ALP are still community products atop of SUSE ALP and thereby exposed to any alterations/disruptions coming from there. Especially looking at the future of a possible Leap successor atop of SUSE ALP, the first thing we probably would need are some kind of stability guarantees, which are very unlikely to happen any time soon. This is however a discussion well beyond the scope of this mailing list. Best, Felix On Thu, 2023-04-20 at 21:16 +0200, Richard Brown wrote:
Hi Felix,
On 2023-04-20 17:17, Felix Niederwanger wrote:
The question is, in it's current state where ALP is basically developed in IBS, is there even a way how people CAN contribute?
I'm saying this as someone who maintains a couple of Tumbleweed packages, and despite several attempts to bring some of them to Leap I gave up at some point because it was basically impossible.
As I tried to explain in my original mail, ALP is built really very differently than everything we’ve built to date.
I’ll try and restate it here to help explain why I don’t share your concern.
Unlike TW, Leap and SLE, ALP doesn’t have a single monolithic codebase in which all packages must go and all products must come out from.
Instead it’s built, kinda in layers
I’ll give simplified examples
ALP:Source:Standard - this is where all the source packages of the “Standard” ALP code “track” will exist. None of the packages will be built here.
Some day there may be other code tracks
ALP:Source:Rolling for example might be what Tumbleweed evolves into some day
So.. that’s the first layer
ALP:Products:FOO is the next layer. This is where packages are actually built, where the products are actually built, ISOs, etc
ALP:Products:FOO May inherit some packages from ALP:Source:Standard
It may inherit packages from other ALP:Source:BAR tracks once they exist
And ALP:Products:FOO may also include packages/containers/flatpaks/whatever that only exist in that product
So, when it comes to contribution
Right now, all the ALP stuff we will be getting from SUSE Will be coming from IBS and I see no good way to create a contribution path to them (FOR NOW)
That is the projects we currently know as:
SUSE:ALP:Source:Standard and the SUSE:ALP:Products:Bedrock and Micro
We’re gonna have openSUSE copies of these, but no good way of contributing back so, for the short term at least, you can think of those ALP Products like ALPs CentOS - a community rebuild of a commercial distro
But, this whole conversation is about what OTHER ALP Products does openSUSE want to make?
We can do whatever we want in our own openSUSE:ALP:Products namespace
And in that namespace, for those products, contribution will be no problem, as we will be doing something very different in scope from SUSEs products
Does this clear up your question?
—- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
On 2023-04-21 08:46, Felix Niederwanger wrote:
We can do whatever we want in our own openSUSE:ALP:Products namespace
which might indicate a possible contribution path.
The openSUSE:ALP:Products will absolutely have a contribution path - no one is going to be putting anything in there without community contributions ;)
This is still a little bit unsatisfactory, as future products developed atop of ALP are still community products atop of SUSE ALP and thereby exposed to any alterations/disruptions coming from there. Especially looking at the future of a possible Leap successor atop of SUSE ALP, the first thing we probably would need are some kind of stability guarantees, which are very unlikely to happen any time soon.
We all agree the status quo is unsatisfactory, but, it's what we can do with what we've got right now - and the limitations in play are coming from all sides, so it's not like anyone can point to either SUSE or openSUSE and say "ya'll should have done better".
This is however a discussion well beyond the scope of this mailing list.
It is, but it isn't - as you eloquently point out, given the symbiotic relationship between SUSE and openSUSE, then openSUSE certainly will have an interest in making sure ALP develops in a compatible way going forward. So, how do I see it developing going forward? Well, once we get these initial ALP offerings out of the way by both SUSE and openSUSE I do want to revisit adding a contribution path into the SUSE-developed parts of the ALP stack. This may leverage the work going on in parallel right now with a git-based workflow, it might not. It might leverage the existing (but pretty painfully flawed) OBS<>IBS request mirroring that we've tried to use with Leap but with pretty significant pain as a result, it might not. I dunno, but, I (and I think everyone else) wants to see some way of community contributions getting into the SUSE developed parts of ALP, just now isn't going to be the time we figure that out. But imagine we get the above all figured out, and implemented. We've have a path to contributing to in-development ALP versions; then there would still be the question of "what about the next ALP version"? We're used to having openSUSE:Factory producing Tumbleweed (which is like SLE) and MicroOS (which is like SLE Micro), and as a result SUSE has a constant rolling reference to draw from that (pretty smoothly) can be pulled and form the basis of their new versions of SLE and SLE Micro. We don't have that for ALP yet, given the very definition of what SUSE ALP is has been under heavy development. So, we absolutely need to look at this issue too, like Alberto said in his suggestion. I'm interested in adapting openSUSE:Factory so it can keep producing Tumbleweed, and MicroOS, and 'next' versions of all the SUSE ALP products. This, arguably, would also be a direct contribution path, maybe not to the exact codebase that SUSE will be using for specific ALP versions, but absolutely to what SUSE will use in future ALP versions. That will come - to be utterly honest it's what I'd much rather be looking at right now instead of everything we're discussing in this thread, but I understand we've got to get some stuff done before I can have fun with that ;) -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
Hey, On 20.04.23 10:27, Richard Brown wrote:
The question really though is, given the above, what does the openSUSE community want to build? (yes..I know, I'm repeating the main question from my original post..but we really do need to have some discussions on that else the answer will be 'nothing')
I'm not sure I agree with how you put this. We are *already* building a thing (Leap) that would be affected by ALP. I would argue we are building Leap by consensus that it's something we want to build. So the more glaring question is: Can we build Leap from ALP or what do we do instead? Henne -- Henne Vogelsang http://www.opensuse.org Everybody has a plan, until they get hit. - Mike Tyson
On 2023-04-20 17:34, Henne Vogelsang wrote:
Hey,
On 20.04.23 10:27, Richard Brown wrote:
The question really though is, given the above, what does the openSUSE community want to build? (yes..I know, I'm repeating the main question from my original post..but we really do need to have some discussions on that else the answer will be 'nothing')
I'm not sure I agree with how you put this. We are *already* building a thing (Leap) that would be affected by ALP. I would argue we are building Leap by consensus that it's something we want to build.
So the more glaring question is: Can we build Leap from ALP or what do we do instead?
I put this like this for 2 reasons 1. Given ALP is a very different distribution from SLE, I expect any derivative of ALP that tries to be like Leap will be a lot more work. This appears to be confirmed by Simon's experiences working towards this for hackweek, hence you see his suggestion being something paired down from Leap, at least with the manpower he currently sees being interested in doing such. 2. ALP is a huge change to how we build stuff, which makes it an opportunity to do something very different, new, different from Leap, different from Tumbleweed, different from MicroOS. Given 1 and 2 I wanted to put this out in a clear "the door is WIDE OPEN" kind of way, to see what responses we get. Asking your version of the question puts us on a path I only want to see us walk if people really step up and want to build it. So far we have Alberto's "build nothing, but work on adapting Tumbleweed to the ALP way" suggestion, and Simons "build something like Leap but focused on the lightweight xfce/enlightenment desktops" That's a good start..I'm looking forward to others -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
On 4/21/23 04:31, Richard Brown wrote:
On 2023-04-20 17:34, Henne Vogelsang wrote:
Hey,
On 20.04.23 10:27, Richard Brown wrote:
The question really though is, given the above, what does the openSUSE community want to build? (yes..I know, I'm repeating the main question from my original post..but we really do need to have some discussions on that else the answer will be 'nothing')
I'm not sure I agree with how you put this. We are *already* building a thing (Leap) that would be affected by ALP. I would argue we are building Leap by consensus that it's something we want to build.
So the more glaring question is: Can we build Leap from ALP or what do we do instead?
I put this like this for 2 reasons
1. Given ALP is a very different distribution from SLE, I expect any derivative of ALP that tries to be like Leap will be a lot more work. This appears to be confirmed by Simon's experiences working towards this for hackweek, hence you see his suggestion being something paired down from Leap, at least with the manpower he currently sees being interested in doing such.
Having spoken with Lubos, i'm probably slightly less pessimistic then that. Some areas will require more work, some areas like python may even be easier then Leap but some things will be harder. For example to get Enlightenment working i'll need to add back parts of X11 but once i've done that, I don't think its going to be significantly more effort for the KDE team to add KDE to the openSUSE ALP then it is for them to add it to Leap, some things will probably even fall out easier. Having said that the main missing part at this point is the Gnome stack, its still pretty unclear if or how much we will get from SUSE there and of that if you want a more "Traditional" Linux setup how much will be useable out of the box. Having said that in a few days Valentin was able to take the Gnome stack from Tumbleweed and get it working, so its certainly doable it might just take someone or a group of someones to commit the time to it. But it might still be that we can recycle the SUSE stuff here but ATM we still don't have enough info from the SUSE Side on what they are going to do there and how its going to work. -- 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 2023-04-21 02:09, Simon Lees wrote:
On 4/21/23 04:31, Richard Brown wrote:
On 2023-04-20 17:34, Henne Vogelsang wrote:
So the more glaring question is: Can we build Leap from ALP or what do we do instead?
I put this like this for 2 reasons
1. Given ALP is a very different distribution from SLE, I expect any derivative of ALP that tries to be like Leap will be a lot more work. This appears to be confirmed by Simon's experiences working towards this for hackweek, hence you see his suggestion being something paired down from Leap, at least with the manpower he currently sees being interested in doing such.
Having spoken with Lubos, i'm probably slightly less pessimistic then that. Some areas will require more work, some areas like python may even be easier then Leap but some things will be harder.
I'm not trying to be pessimistic but pragmatic. Given folk like you and Lubos will actually be doing more of the work once we're set on a course, I'm totally fine with you being wayyyy more optimistic than me :)
Having said that the main missing part at this point is the Gnome stack, its still pretty unclear if or how much we will get from SUSE there and of that if you want a more "Traditional" Linux setup how much will be useable out of the box. Having said that in a few days Valentin was able to take the Gnome stack from Tumbleweed and get it working, so its certainly doable it might just take someone or a group of someones to commit the time to it. But it might still be that we can recycle the SUSE stuff here but ATM we still don't have enough info from the SUSE Side on what they are going to do there and how its going to work.
Well I figured this might be obvious by omission, but I'll share how I understand the current situation SUSE has no immediate plans for an ALP Desktop _product_ SUSE is investigating having a Desktop _workload_ that can be run atop it's ALP Products, like the Bedrock and Micro servers you currently see in the current prototypes. All the work in this area I've seen so far involve crazy-interesting containerised stuff, like https://github.com/fcrozat/gdm-container So, if I understand your goal correctly, building an openSUSE ALP Distro that offers a very 'traditional' desktop experience, I'd expect that you won't be able to draw much from SUSE's current ALP Desktop efforts as they appear to be primarily 'non-traditional'. So yeah, for any of the Desktops in your suggested openSUSE ALP Product, I'd say you're going to need someone/or a group of people to step up and commit the time to it. -- Richard Brown Distributions Architect SUSE Software Solutions Germany GmbH, Frankenstraße 146, D-90461 Nuremberg, Germany (HRB 36809, AG Nürnberg) Managing Directors/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
Hi Richard, I am a TW user and don't think I'll be using ALP but I installed MicroOS in a VM to get a feel for how the transactional-update process works. Since the root fs is read only, I see that overlays are used for /etc with directories created under /var/lib/overlay which corresponding to each of the rootfs snapshots. On my systems I am often creating my own snaphots for various reasons but since /etc is no longer part of the rootfs snapshot, it kind of breaks the snapshot/rollback process for snapshots that were not created as part of the transactional-update process. I guess one could create the directory under /var/lib/overlay for snapshots not created by transaction-update but that seems like a hack. Are there plans to address that issue or is that a method I am not aware of with transactional-updates to also make it easy for other admin created snapshots ? It seems that the same situation will exist with ALP ? Joe On 4/20/23 15:01, Richard Brown wrote:
On 2023-04-20 17:34, Henne Vogelsang wrote:
Hey,
On 20.04.23 10:27, Richard Brown wrote:
The question really though is, given the above, what does the openSUSE community want to build? (yes..I know, I'm repeating the main question from my original post..but we really do need to have some discussions on that else the answer will be 'nothing')
I'm not sure I agree with how you put this. We are *already* building a thing (Leap) that would be affected by ALP. I would argue we are building Leap by consensus that it's something we want to build.
So the more glaring question is: Can we build Leap from ALP or what do we do instead?
I put this like this for 2 reasons
1. Given ALP is a very different distribution from SLE, I expect any derivative of ALP that tries to be like Leap will be a lot more work. This appears to be confirmed by Simon's experiences working towards this for hackweek, hence you see his suggestion being something paired down from Leap, at least with the manpower he currently sees being interested in doing such.
2. ALP is a huge change to how we build stuff, which makes it an opportunity to do something very different, new, different from Leap, different from Tumbleweed, different from MicroOS.
Given 1 and 2 I wanted to put this out in a clear "the door is WIDE OPEN" kind of way, to see what responses we get.
Asking your version of the question puts us on a path I only want to see us walk if people really step up and want to build it.
So far we have Alberto's "build nothing, but work on adapting Tumbleweed to the ALP way" suggestion, and Simons "build something like Leap but focused on the lightweight xfce/enlightenment desktops"
That's a good start..I'm looking forward to others
-- Regards, Joe
On Sat, Apr 22, Joe Salmeri wrote:
Hi Richard,
I am a TW user and don't think I'll be using ALP but I installed MicroOS in a VM to get a feel for how the transactional-update process works.
Since the root fs is read only, I see that overlays are used for /etc with directories created under /var/lib/overlay which corresponding to each of the rootfs snapshots.
On my systems I am often creating my own snaphots for various reasons but since /etc is no longer part of the rootfs snapshot, it kind of breaks the snapshot/rollback process for snapshots that were not created as part of the transactional-update process.
If you create an snapshot of your own, it's 1:1 identical to the already existing read-only snapshot. Means it includes /etc and the configuration for the overlays.
I guess one could create the directory under /var/lib/overlay for snapshots not created by transaction-update but that seems like a hack.
Are there plans to address that issue or is that a method I am not aware of with transactional-updates to also make it easy for other admin created snapshots ?
If you can come up with a real good use case, why somebody need to create identical snapshots themself, we can look at it. Currently I don't see such an use case, except making the current code even more complex for duplicate data. If you want to keep a snapshot, there is no need to create a new one, just tell snapper to not delete the existing one when doing the cleanup. Thorsten
It seems that the same situation will exist with ALP ?
Joe
On 4/20/23 15:01, Richard Brown wrote:
On 2023-04-20 17:34, Henne Vogelsang wrote:
Hey,
On 20.04.23 10:27, Richard Brown wrote:
The question really though is, given the above, what does the openSUSE community want to build? (yes..I know, I'm repeating the main question from my original post..but we really do need to have some discussions on that else the answer will be 'nothing')
I'm not sure I agree with how you put this. We are *already* building a thing (Leap) that would be affected by ALP. I would argue we are building Leap by consensus that it's something we want to build.
So the more glaring question is: Can we build Leap from ALP or what do we do instead?
I put this like this for 2 reasons
1. Given ALP is a very different distribution from SLE, I expect any derivative of ALP that tries to be like Leap will be a lot more work. This appears to be confirmed by Simon's experiences working towards this for hackweek, hence you see his suggestion being something paired down from Leap, at least with the manpower he currently sees being interested in doing such.
2. ALP is a huge change to how we build stuff, which makes it an opportunity to do something very different, new, different from Leap, different from Tumbleweed, different from MicroOS.
Given 1 and 2 I wanted to put this out in a clear "the door is WIDE OPEN" kind of way, to see what responses we get.
Asking your version of the question puts us on a path I only want to see us walk if people really step up and want to build it.
So far we have Alberto's "build nothing, but work on adapting Tumbleweed to the ALP way" suggestion, and Simons "build something like Leap but focused on the lightweight xfce/enlightenment desktops"
That's a good start..I'm looking forward to others
-- Regards,
Joe
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
If you create an snapshot of your own, it's 1:1 identical to the already existing read-only snapshot. Means it includes /etc and the configuration for the overlays.
Thanks Thorsten that was very helpful and I appreciate it! I have not used mount overlays before so I had to do some reading. One reason I thought there was an issue is because when I did snapper create -d "test" It created snapshot 11 ( in /.snapshots/11/snapshot ) but since there is no /var/lib/overlay/11 folder I incorrectly concluded that it would be a problem at boot as it would not have an overlay for etc for snapshot 11. I now see that since the overlays are stored on the /@var subvolume, and since /etc is an overlay, that snapshot 11 has etc in /.snapshots/11/snapshot/etc and that the fstab there is using overlay 9 and overlay 10 ( just like it did for snapshot 10 - the current default/booted snapshot ) Did I get that all right ? I did find something that was broken by the R/O root fs. mksubvolume is a convenience program to make it easy to create new subvolumes whose parent subvolume is the /@ subvolume. It creates the subvolume with /@ as the parent, adds the /etc/fstab entry to mount it, but then fails when it tries to create the folder for the mountpoint because the root fs is R/O. Manually doing the steps is not hard mount /dev/sdaX /mnt -o subvol=/ btrfs subvolume create /mnt/@/myvol Add to /etc/fstab systemctl daemon-reload But you still have the issue of how to create the folder for the mount point btrfs property set /.snapshot/10/snapshot ro false mkdir /.snapshots/10/snapshot/myvol btrfs property set /.snapshot/10/snapshot ro true mount /myvol It seems like the R/O root did not take into consideration a user needing to add mount points for other drives. I have many drives in my system for different uses. Is there a better way to add the additional mount points that I have missed ?
If you can come up with a real good use case, why somebody need to create identical snapshots themself, we can look at it. Currently I don't see such an use case, except making the current code even more complex for duplicate data.
If you want to keep a snapshot, there is no need to create a new one, just tell snapper to not delete the existing one when doing the cleanup.
Thanks, your response has caused me to think through the main reasons I have created my own snapshots. It seems they fall into 2 categories. The first reason is because the snapshot descriptions for snapshots that zypper creates are not real useful IMHO. When I install something I have used the following so I have a good description on the pre/post snapshots. snapper create -d 'install programXYZ' --command 'zypper install programXYZ' zypper does not have a way that I've found to provide a meaningful snapshot description as a parameter. I considered using the --userdata option but that seems to be used for key/value pairs and is already used for things like marking a snapshot as important so I didn't want to mess with that. If zypper provided a way to also specify what the description was that would address that. I guess, one other option would be to just modify the description after the fact using 'snapper modify SnapShot# -d "New description". The descriptions are no better with transactional-update as doing a pkg install will just have a description of "Snapshot Update of #XX". While that is technically correct it is also not very useful and having to do a snapper status x..y to figure out what occurred in that snapshot is a pain and could be error prone, especially if multiple things were done. The second reason that I create my own snapshots is because I like to manually cleanup snapshots that I have created and not have them subject to the cleanup algorithm settings in the snapper config for the volume. My manually created snapshots never have a cleanup algorithm therefore they will never be deleted until I decide to do so which is also why having meaningful names is really important to me. If it really is a zypper dup update than DUP would be fine but snapshots are often created for other points in time which were not DUPS. Also, when you do "transactional update cleanup" it can change a snapshot from no cleanup to number cleanup and also add "important=yes" to the userdata. For example snapshot #10 had no cleanup and no userdata and then after running 'transactional update cleanup' it changed snapshot 10 to number cleanup and added "important=yes" to the userdata. I have not seen it mess with snapshots I created manually which I suspect is because it deemed them not important like a zypper dup would be. I get your point though about creating identical snapshots and agree that with the root fs R/O that need does not exist but it would be nice if there was a way to specify the description to use for a snapshot when doing transactional-update as well as specifying how we'd like the snapshot cleaned up and also not have it be later modified when transactional-update cleanup is run. Hope that helps explain my use cases. Regards, Joe
Thorsten, One other thing I noticed that seemed odd. Assuming snapshot #13 is the latest and current snapshot that is booted. If you run transactional-update dup the results are: Checking for newer version. transactional-update 4.1.5 started Options: dup Separate /var detected. 2023-04-25 13:32:18 tukit 4.1.5 started 2023-04-25 13:32:18 Options: -c13 open 2023-04-25 13:32:19 Using snapshot 13 as base for new snapshot 14. 2023-04-25 13:32:19 Syncing /etc of previous snapshot 12 as base into new snapshot "/.snapshots/14/snapshot" 2023-04-25 13:32:19 SELinux is enabled. ID: 14 2023-04-25 13:32:22 Transaction completed. Calling zypper --no-cd dup zypper: nothing to update Removing snapshot #14... 2023-04-25 13:32:26 tukit 4.1.5 started 2023-04-25 13:32:26 Options: abort 14 2023-04-25 13:32:28 Discarding snapshot 14. 2023-04-25 13:32:29 Transaction completed. transactional-update finished I understand using snapshot 13 as the base for snapshot 14 which is where the dup would run, but why is it syncing /etc from snapshot 12 into snapshot 14, shouldn't it be syncing the current snapshot 13 into 14 ? Seems like if 13 had and changes to etc those would be lost ? What am I missing ? Thanks!
On Tue, Apr 25, Joe Salmeri wrote:
I understand using snapshot 13 as the base for snapshot 14 which is where the dup would run, but why is it syncing /etc from snapshot 12 into snapshot 14, shouldn't it be syncing the current snapshot 13 into 14 ?
No, this is correct.
Seems like if 13 had and changes to etc those would be lost ?
No, they will not.
What am I missing ?
Please look at /etc/fstab which overlays are mounted. There are always two overlays mounted, so that no changes done after the new snapshot gets created go lost. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)
On 4/25/23 14:12, Thorsten Kukuk wrote:
Please look at /etc/fstab which overlays are mounted. There are always two overlays mounted, so that no changes done after the new snapshot gets created go lost.
Thorsten
Thanks Thorsten, I saw that there were always 2 overlays mounted but the syncing part was still confusing me so I downloaded the source code for transactional-update to get a better understanding of what it was actually doing. In case anyone else is trying to understand the how the overlays are managed, just look at the transactional-update source code in the lib/Overlay.cpp file at the Overlay::sync method for the details. -- Regards, Joe
On 4/18/23 17:49, Richard Brown wrote:
What does everyone think?
Sorry to chime in a bit late and as someone who is "just" a user and (very) interested follower of openSUSE. I'm running my desktop and laptops on x86_64 Tumbleweed, and some Raspberry Pis on ARM Tumbleweed, and I'm generally quite happy with those. Also, I'm running my 2 servers on x86_64 Leap and wonder what the future will look like for those. I can't switch them to a transactional system easily, that would require extensive downtimes and completely reworking the setup, which I'd not be looking forward to. That said, I completely would be happy there if there was e.g. a snapshot of Tumbleweed every 6 months that would undergo a few weeks of stabilization and testing and security maintenance until a few months after the next such snapshot was released. I know this would be yet another model and probably not something people want to use time on, but I wanted to mention it as a somewhat rough idea. I'd definitely be happy to get updates to many packages of the system way more often than current Leap while still having stability for multiple months. But if there is an ALP-based Leap that is similar to current Leap and doesn't require me to re-work the server setups, I'm pretty happy as well. :) Just wanted to add my 2c as a user. Cheers, KaiRo
participants (18)
-
Andrei Borzenkov -
aplanas -
Atri Bhattacharya -
Charlie Chan -
Dan Čermák -
Felix Niederwanger -
Henne Vogelsang -
Jan Engelhardt -
Joe Salmeri -
Lubos Kocman -
Neal Gompa -
Richard Brown -
Robert Kaiser -
Roger Oberholtzer -
Simon Lees -
Stefan Seyfried -
Thorsten Kukuk -
Vojtěch Zeisek