New subject: Proposal: Creating a Leap replacement based on ALP. (Grassy Knoll?)

3 Feb 2023

      This hackweek a group of us have been looking at using the ALP binaries 
provided by SUSE to create a functional successor to openSUSE Leap.

**Goals:**
   * Creating and maintaining it should be manageable by a small number 
of community volunteer maintainers,
      but at the same time should be scalable to grow with additional 
contributors.
   * It should be possible for community members to easily contribute 
additions in their preferred form whether
      rpm, container or something else.
   * Use ALP Sources wherever possible (In some cases this may require 
building them in a different format).
   * Make it possible to support smaller desktops including supporting 
X11, Wayland and xwayland.
   * Support upgrading systems from Leap 15.5 in most cases. This will 
likely mean alongside supporting
     transactional updates so that SUSE:ALP -> openSUSE:ALP is possible, 
it also needs to be possible to still
     support traditional RW filesystems with zypper up and dup.
   * Support running ALP containerised workloads but aim to avoid using 
containers in core operating system
      components.
   * Provide a lightweight environment for embedded usecases including 
Raspberry Pi's.

To test that these goals are realistic, our main goal for this hackweek 
was to get Xfce running on a combination of ALP and backports packages. 
It seemed like a good choice as the package set is small enough to be 
handled by a couple of people and it's popular in the openSUSE 
community. We have made good progress and have achieved a lot, but more 
on that later.

**Design:**
The basic concept is to follow what we have done with Leap and create a 
"Backports" repository containing community packages from Tumbleweed to 
fill the gaps, one of the differences here is SUSE's repos for SLE 
contain around 10,000 packages while ALP contains around 2,000, despite 
this, we only had to add around another 350 packages to reach our 
initial goals. This includes yast and many gnome build dependencies that 
hopefully we will be able to take from ALP Sources once they are there. 
But even at this number it is probably manageable for a small team 
especially while the packages are present in Tumbleweed.

Once we had the packages we needed, we could use our existing tooling 
such as kiwi to create images for testing including livecds. The biggest 
benefit to SUSE's Factory first policy is with the right packages 
everything that works in Tumbleweed also works here. Hopefully once we 
know how SUSE plans to build their container images, we will also be 
able to use the same approach partnered with the backports repo to build 
openSUSE community images if people are interested in maintaining them. 
We didn't investigate that this hackweek though.

Lubos also spent a significant portion of his hackweek working with 
d-installer to see if it is currently suitable for working with the 
additional features that we require.

**Design Limitations:**
While it is possible to work around many of ALP's restrictions via 
simply building images differently, some other design decisions are hard 
to avoid due to the fact ALP binaries are built without certain features 
such as AppArmor and NIS.

**Results:**
Firstly we have a backports repository here[1] containing all the 
additional packages we required so far, we also have a wiki page 
documenting why many of these packages are required [2].
Secondly we built several KVM Images available for downloading and 
testing [3], that include Xfce, Enlightenment and a generic console 
environment. These are very limited images - really only designed as a 
proof of concept, so beyond very basic functionalities and basic desktop 
options, don't expect too much.
Third we built live cds also for testing and available to download [4]. 
Initially we worked on Xfce and Enlightenment due to my personal 
interest but at that point Valentin discovered that we were only about 
30 packages away from a usable Gnome system and decided to give it a 
shot. However, what Gnome ends up looking like in the future will depend 
a fair bit on what SUSE does with it for their ALP products. We also 
have a D-Installer image availiable as a proof of concept for installation.

**Unanswered Questions:**
   * Desktop apps - SUSE's ALP will likely use Flatpaks, if these are 
built on OBS, it may be possible to build rpm
     versions from the same source. It is also likely that some openSUSE 
contributors will prefer to ship their
     applications as rpms. So Ideally we want to support both.
   * Maintenance / Release schedule - Ideally during the year at 
scheduled periods, we will bundle up changes
     from SUSE's ALP and the community and bundle them into some form of 
point release. I.e. it seems likely that
     SUSE will release the python3.11 stack at a point when the 
python3.10 stack is still supported so it would be
     ideal to pick one point to do regular migrations rather then them 
happening at random times. Currently we
     still don't have enough detail in this area to really assess what 
will be possible though.
     * There  is a chance that SUSE will use less repositories than in 
the past and we may need to add repository- based filtering to zypper / 
yast so that they only show still supported packages for install. But 
again we are
       very much waiting for more detail here.

**What Next:**
We now know that this concept A works and B would be maintainable, so if 
there is broad community interest in this concept, the next step would 
be probably after the Leap 15.5 release, creating a backports package 
repo similar to the way the Leap ones have existed with bots etc. Then 
getting maintainers to contribute any other packages they wish to 
maintain. At the same time, setting up image building and openqa tests. 
In the meantime the packages in the backports repo under my namespace 
are mostly linked from Factory (i'll fix the rest) so i'll keep an eye 
on them and check they stay building. If you maintain a package and are 
interested in the list of dependencies, you'd also need to maintain to 
get it working, let me know and I can link it in from Factory. However, 
be aware that significant parts of the perl, python and ruby language 
stacks etc aren't packaged yet. Also in the spirit of lighter desktops 
i'd like to get sway packaged as well as it will give a good indication 
of whats needed for the other smaller wayland desktops.

The name is something else to consider, should we just use Leap for the 
open source builds of SUSEs ALP products, should we do something else 
entirely? Given that SUSE is using names of alps as release code names I 
chose to do something similar but different, This project is meant to be 
less extreme then a trip up into the alps, more like a relaxing picnic 
or stroll through the hills so this prototypes codename is Grassy Knoll 
because it sounds cool and maybe I've been playing too much dwarf 
fortress. Either way, it may not be the best name for the project long term.

**FAQ:**
   * Why didn't we look at KDE? - KDE has a much larger packet set, Also 
part of my initial goal was to create
     something small enough that if I needed to maintain it with a 
couple of people mostly for our own personal
     usecases we'd be able to. KDE doesn't fit within that scope, 
however from the testing we have done this week
     if someone wanted to maintain KDE, it shouldn't require too many 
changes from the packages in Tumbleweed
     and may provide a good way to do KDE going forward with ALP but 
i'll leave that decision with the KDE
     Maintainers

Finally a massive thanks to the other members of this hackweek team: 
Maurizio Galli, Lubos Kocman and Valentin Lefebvre. They took a concept 
I had in my head and helped transform it into a functioning prototype. 
Also a big thanks to Fabian Vogt for answering all my "why won't kiwi 
build this"-questions.

If you have questions thoughts or suggestions feel free to reach out to 
us via email or in the openSUSE-ALP channels on Discord / IRC / Matrix. 
we will also work on getting this information into the wiki.

1. 
https://build.opensuse.org/project/show/home:simotek:GrassyKnoll:Backports
2. https://en.opensuse.org/User:Simotek:GrassyKnoll
3. 
https://mirrorcache-au.opensuse.org/repositories/home:/simotek:/GrassyKnoll:...
4. 
https://mirrorcache-au.opensuse.org/repositories/home:/simotek:/GrassyKnoll:...

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

Proposal: Creating a Leap replacement based on ALP.

Simon Lees

Lew Wolfgang

Simon Lees

Per Jessen

Neal Gompa

Robert Webb

Olaf Hering

Jan Engelhardt

Larry Finger

Mathias Homann

Larry Finger

Patrick Shanahan

Jan Engelhardt

Simon Becherer

Lew Wolfgang

Jan Engelhardt

Jacob Michalskie

Carlos E. R.

Robert Webb

Carlos E. R.

Robert Schweikert

Robert Schweikert

Simon Lees

Robert Schweikert

Patrick Shanahan

Lubos Kocman

Neal Gompa

Simon Lees

Mathias Homann

Simon Lees

Maurizio Galli

Johannes Meixner

Martin Wilck

Simon Lees

doug demaio

tags

participants (19)