From a technical perspective the simplest way to summarize the project would be to create a very slow rolling Tumbleweed, to the point where once ALP is released Grassy Knoll will have an update say every 3 or 6 months taking in the new packages. We will need more detail about ALP's component lifecycle before we can confirm this but 6 months would be more ideal.
Like Leap before it and Tumbleweed, Grassy Knoll is not intending to use transactional updates or containers as part of its "core" operating system, however ideally it will be able to still run ALP's containerised workloads. The plan for "Grassy Knoll" is to use a "Backports" repository to allow community package submissions.
- Wont use transactional updates
- Wont use containers in the core of the OS but will support running containerized workloads from ALP
- Be a base that's easy for the community to build on.
- Support X11 Desktop Environments
- Be an Ideal solution for embedded systems.
- Migration from Leap 15 systems
- Continue to offer desktop apps as rpm's where possible.
- Packages SUSE ALP supports in "Bare Metal Mode"
- KVM Server
- Anything else people would like to contribute.
- aarch64 (Raspberry Pi)
The reason for this scope is these are the requirements for my personal KVM Desktop Server alongside XFCE as its a popular community option. This is what I could commit to maintaining at a stretch it should also be enough to have a base for many other community packages. The idea is we will add more as people step up to help.
Goals achieved during Hackweek 2023
- Setup a "Backports" repository for "Community Packages"
- Created a basic generic kvm image based on ALP
- Created desktop KVM (qcow2) images for Enlightenment, GNOME and Xfce
- Created desktop Live CD (iso) images for Enlightenment, GNOME and Xfce
- Setup basic openQA testing based off existing tumbleweed tests.
- Create a Raspberry Pi image for testing
- KDE images
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.
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.
Firstly we have a backports repository containing all the additional packages we required so far, we also have a wiki page documenting why many of these packages are required you can find both linked from this wiki. Secondly we built several KVM Images available for downloading and testing, 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. 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. Again you should be able to find links these on this page.
- 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.
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.
- 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
Dependencies trackingList of package dependencies