Bringing openSUSE Leap and SLE closer

Enterprise Linux Next has more or less existed in openSUSE for a while, as the relationship for SLE to openSUSE is "factory first". This change was enforced with SUSE Linux Enterprise 15 development, where the branching from openSUSE Factory (the distribution project that makes up Tumbleweed) was publicly done and SLE 15 was actively developed as Leap 15 from the beginning.

What's going on here is that in order to make it easier for customers to "upgrade" from openSUSE Leap to SUSE Linux Enterprise without making things too messy, they want to stop having the released openSUSE Leap distribution being based on a complete rebuild of the sources. The reason for this comes simply down to abuse of the ability to turn off features for SUSE Linux Enterprise (or said another way, turn on features only for openSUSE Leap). This has made migrations from Leap to SLE very challenging as it winds up being a downgrade in experience in some circumstances.

Additionally, some behind the scenes work has led to SUSE PackageHub (their equivalent of Fedora EPEL) being automatically populated with the delta between SUSE Linux Enterprise and openSUSE Leap... mostly. Again, this is where the conditional features come into play. Some of the quirks in supporting PackageHub have led to scenarios where hacks have to be implemented to make things build properly, when the correct solution was to make SLE more like openSUSE Leap so that things are more consistent.

What this "JUMP" project aims to do is integrate as many (hopefully all!) features in openSUSE Leap that do not exist in SLE, then rework things so that SLE builds are just merged into openSUSE Leap as a "underlay" of packages. The end result would be that openSUSE Leap would be comprised cleanly of two layers: the SUSE supported SLE layer, and the community supported Leap layer. These two layers can be then trivially decomposed and shipped as separate things for customers without damaging the integrity anywhere.

Essentially, an equivalent way this would work in Fedora is if through ELN, RHEL 9 is branched directly in Fedora's Dist-Git. Not in some random downstream Dist-Git in Red Hat. Nor would it be popping up in some broken form in CentOS. It would just be a regular branching event, and the releng processes around RHEL 9 would just kick in from there. There would either be a separate Koji for it (similar to how SUSE builds with a separate OBS instance they call IBS), or it'd be more integrated. From there, you can produce the same "layer cake": EPEL could be automatically composed of the delta between RHEL 9 and Fedora, and it would be essentially trivial to maintain packages for RHEL 9 because from the Fedora packager perspective, it works exactly as any other Fedora package. And if an EPEL package becomes a RHEL package, it'd be known because the Dist-Git rights would change. Then you'd have a "Fedora CentOS" release based on RHEL 9 + EPEL for the community, and then Red Hat ships RHEL without the EPEL bits, but you can add them back in trivially (admittedly without support for those bits). This would mean that "Fedora CentOS" would probably be shipping the same binary packages as RHEL (signatures and all), but why not? It would make switching between "Fedora CentOS" and "Red Hat Enterprise Linux" trivial.