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%C2%A0or https://en.opensuse.org/openSUSE:ALP/Workgroups/GrassyKnoll%C2%A0should 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.

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,

How would things like NVIDIA drivers work? Could they easily be updated by a user in an ALP system?

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.

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')

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 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

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. :-)

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

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

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.

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 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 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.

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.

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

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

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

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 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.

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.