The Fedora Linux developers announced the formation of the SIG group ( Special Interest Group ) to support the project ELN (Enterprise Linux Next), which aims to provide continuous builds of Red Hat Enterprise Linux based on the Fedora Rawhide repository. The process of developing new RHEL branches implies the creation of a branch from Fedora every three years, which is developed separately for some time, until it is brought to the final product. ELN will allow you to emulate Red Hat Enterprise Linux builds based on an arbitrary snippet from the Fedora Rawhide repository.
Since the Fedora fork, RHEL preparation has been done behind closed doors. With CentOS Stream, Red Hat intends to make the RHEL development process more open and transparent to the community. ELN aims to make Fedora’s fork of CentOS Stream / RHEL Next more predictable by employing techniques similar to continuous integration systems.
ELN will provide a separate buildroot and build process to rebuild the Fedora Rawhide repository as if it were RHEL. Successful ELN rebuilds are planned to be synchronized with experimental builds of RHEL Next, adding additional changes to packages that are not allowed in Fedora (for example, adding trademarks). At the same time, developers will try to minimize the differences by separating them at the level of conditional blocks in spec files.
Using ELNs, Fedora maintainers will be able to catch and test early changes that could potentially impact RHEL development. Among other things, it will be possible to check the intended changes of conditional blocks in spec files, i.e. Build a package when conditions are triggered with “% {rhel}” set to “9” (ELN variable “% {fedora}” will return “false”), simulating building a package for a future RHEL branch.
ELN will also allow you to experiment with new ideas without affecting core Fedora builds. This includes ELNs that can be used to test Fedora packages under new compiler flags, disabling experimental or unsuitable RHEL features, changing hardware architecture requirements, and enabling additional CPU extensions. For example, without changing the regular package building process in Fedora, you can simultaneously test a build with support for AVX2 instructions enabled, then evaluate the performance impact of using AVX2 in packages and decide to implement the change in the main Fedora distribution.