Bringing openSUSE Leap and SLE closer

SUSE and openSUSE

SUSE Linux is one of the oldest Linux distributions still in existence today, with a history that starts in 1994. Today it exists in a few forms, including the commercial SLE offering, which mainly targets the server market.

The openSUSE project creates a community version of the SUSE distribution; its work is largely sponsored by SUSE (the company). OpenSUSE produces two main variants, the relatively stable openSUSE Leap and a rolling version called openSUSE Tumbleweed. Leap is built on packages from SLE, which form a stable base made up of relatively old software releases. For example, the Leap kernel version is the same as in the corresponding SLE version. The openSUSE team adds some changes to the SLE packages, then rebuilds them for Leap; the team also adds newer versions of some packages, such as desktop environments, from Tumbleweed. The current version of Leap is 15.1 (as of April 2020).

The proposal

As stated in the announcement, the main goal of this unification is to bring the SLE and openSUSE Leap distributions closer together. The proposal has been presented to the SUSE management and to the openSUSE board. SUSE's exact motivation is not clearly stated, but two main themes have shown up in the discussion: allowing SLE to easily take advantage of the work in openSUSE, and easing the transition between Leap systems and SLE. The first point, in particular, led to comments from the community; for example, Stasiek Michalski wrote:

Among responses to this statement, John Paul Adrian Glaubitz reminded participants of some basic free-software principles: "The whole point of releasing your software under a free license is to allow it to be re-used by other projects and commercial products". The benefits for the community, instead, are said to be better quality through common testing, bug reporting, and code cleanup in the packages.

The core of the proposal is to include SLE binaries directly into openSUSE Leap. The process toward this goal is expected to involve three steps. The first is to perform a code cleanup in the packages that are currently shared between openSUSE Leap 15 and SLE 15; this process has already started from the SUSE side and will delay the next SUSE release (SLE 15 SP2) to July 2020. The next Leap release will also probably be delayed to accommodate these changes; the openSUSE Leap 15.2 release is now expected in July 2020 as well.

Then, the plan is to provide two releases of Leap in parallel around October 2020: one (called "Jump" for now) will contain the SLE binaries, while the other will have those packages rebuilt by the openSUSE team (as has been done until now). This will be the time to discuss the results so far and for the community to decide whether to go further with the project. If everything goes smoothly, the Leap release after 15.2 should include the SLE binary packages by default; it should be available around July 2021.

To reach the goal, changes in the build systems will be necessary. Currently SUSE is using its own instance of the build system (called "Internal Build Service"), and openSUSE uses the public openSUSE Build Service (OBS). A large part of the work will be in the setup of the projects in OBS and the migration scripts for synchronization of packages between the two distributions.

Another important part of the puzzle will be synchronizing the changes openSUSE makes to the SLE packages it uses. The plan proposes to adapt the spec files and unify the versions of those packages. That should have limited impact on openSUSE Leap, except for some package-version changes. The exact procedure for handling the differences is not defined yet. Multiple ideas have been proposed, including implementing the openSUSE changes in SLE, splitting the packages when needed, and using the /etc/os-release file during installation to perform different actions depending on the distribution to avoid hard-coding the conditions in the spec files.

SLE and openSUSE support different sets of architectures. Those supported by SLE (aarch64, x86-64, ppc64le, and s390x) are also available in Leap. However, the community will have to find a way to integrate the SLE binary packages in the build system in such a way that still allows building packages for the ARMv7 and RISC-V architectures, which are supported by Leap, but not SLE.

The licensing (GPL) of openSUSE Leap and the maintenance process are going to stay as they are today. The proposal FAQ clearly mentions that no registration will be required to download openSUSE Leap.

Community reaction

The proposal has been posted to the openSUSE project list and to the Factory development list for discussion on both technical and project levels. The discussion resulted in mostly positive reactions. However, some doubts and issues have been expressed.

Michalski asked about the differences in the content of SLE and Leap, especially in the branding packages. Adrian Schröter explained that the two distributions will have different configurations that will be used to select distribution-specific options like branding packages.

Another discussion concerned the signatures on Leap packages. "Cunix" asked why binary packages can go from SLE into openSUSE, but it isn't possible to import openSUSE packages into SLE. This requires openSUSE users to accept the SLE signing key. Robert Schweikert responded that this is driven by security certifications that require SLE binaries to be built on the SUSE-controlled internal build system. Following that, cunix suggested that a solution should be found to allow a package to have two signatures, one from openSUSE and one from SUSE. Unfortunately this is currently not possible, and there were no other developers preferring that solution.

SUSE also expects to set up an easier process for updating a Leap package that comes from SLE, but the details are not known yet. This will replace the current process, where somebody has to contact the openSUSE package maintainer, who then turns that request into a SLE feature request. Matwey V. Kornilov commented that the ability to directly file a SLE feature request will be necessary, and the current process may take a long time. The same type of issue was mentioned by Wolfgang Rosenauer, who said that, in some cases, such updates were rejected without a clear reason. Lubos Kocman promised that these problems will be addressed by the new process.

Fedora Enterprise Linux Next

A similar idea is being developed in the Fedora project under the name "Enterprise Linux Next buildroot and compose" (or just ELN). "Buildroot" in this context means a chroot environment used to install packages in the build system. The idea is to use this buildroot, which is configured like the commercial Red Hat Enterprise Linux (RHEL) distribution, to create a build of the unstable Fedora Rawhide offering. Or, as the proposal puts it: "The main goal of ELN is to rebuild Fedora Rawhide as if it were RHEL" This will make it easier for Fedora developers to see how their changes will affect RHEL and, thus, ease the process of moving Fedora work into the enterprise distribution.

The addition of the ELN buildroot has just been approved by Fedora Engineering Steering Committee (FESCo).

As with SUSE's proposal, ELN buildroot will allow easier integration of Fedora's changes into RHEL. One difference is that ELN builds do not include RHEL binaries, so there seems to be no question about the package signatures, as in the openSUSE case. Additionally, Fedora decided to allow differences in the spec files (different variables for ELN, Fedora, and RHEL), while openSUSE seems to be targeting more unification.

Next steps

Synchronizing sources between related distributions clearly has the potential to reduce the amount of work done by both teams and to allow commercial distributions to benefit more easily from work done in their community versions. The question remains how the community and company teams will be able to work together.

On the openSUSE side, the comments are generally positive, it seems that the project will go forward. Both SUSE and openSUSE teams will have work to do to resolve the remaining issues. The next big step will happen in late 2020, when the prototype Leap version with the SLE packages is expected to be available and we see what the conclusions of both teams will be. That will also probably be the time to compare the experiences of openSUSE and Fedora's ELN.