The Fedora Linux developers have announced the formation of a SIG (Special Interest Group) to support the ELN (Enterprise Linux Next) project, aimed at providing continuously evolving builds of Red Hat Enterprise Linux based on the Fedora Rawhide repository. The process of developing new branches of RHEL involves creating 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 a slice from the Fedora Rawhide repository created at any time.
Until now, after the Fedora fork, the preparation of RHEL was carried out 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 CentOS Stream/RHEL Next fork more predictable by using methods similar to continuous integration systems.
ELN will provide a separate buildroot and build process that allows you to rebuild the Fedora Rawhide repository as if it were RHEL. Successful ELN builds are planned to be synchronized with experimental builds of RHEL Next, adding additional changes to the packages that are not allowed in Fedora (for example, adding brand names). At the same time, developers will try to minimize the differences by separating them at the level of conditional blocks in spec files.
With ELN, Fedora package maintainers will be able to early catch and test changes that could potentially impact RHEL development. In particular, it will be possible to check the intended changes to conditional blocks in spec files, i.e. build a conditional package with the "%{rhel}" variable set to "9" (the "%{fedora}" ELN variable will return "false"), simulating building a package for a future RHEL branch.
ELN will also allow you to experiment with new ideas without affecting the main Fedora builds. ELN can also be used to test Fedora packages against new compiler flags, disable experimental or non-RHEL features, change hardware architecture requirements, and enable additional CPU extensions. For example, without changing the standard process for building packages in Fedora, you can simultaneously test the build with support for AVX2 instructions enabled, then evaluate the performance impact of using AVX2 in packages and decide whether to implement the change in the main Fedora distribution.
Source: opennet.ru