The Fedora Linux developers announced the formation of a SIG (Special Interest Group) to support the ELN (Enterprise Linux Next) project, aimed at providing continuously built versions of Red Hat Enterprise Linux based on the Fedora Rawhide repository. The development process for new RHEL branches involves creating a fork from Fedora every three years, which develops separately for a while until it is turned into a final product. ELN will allow for the emulation of Red Hat Enterprise Linux builds based on snapshots from the Fedora Rawhide repository created at any point in time.
Until now, after forking from Fedora, the preparation of RHEL was conducted behind closed doors. With the help of CentOS Stream, Red Hat aims to make the RHEL development process more open and transparent for the community. ELN aims to make the forking stage of CentOS Stream/RHEL Next from Fedora more predictable by applying methods similar to continuous integration systems.
ELN will provide a separate buildroot and build process, allowing the reassembly of the Fedora Rawhide repository as if it were RHEL. Successful ELN reassemblies will be synchronized with experimental RHEL Next builds, adding further changes to packages that are not permitted in Fedora (such as the addition of trademarks). Developers will strive to minimize differences by separating them at the conditional block level in spec files.
With the help of ELN, associated Fedora packages will have the opportunity to catch and test changes at an early stage that could potentially impact RHEL development. This will include the ability to verify proposed changes in conditional blocks in spec files, i.e., to build a package triggered by conditions with the variable "%{rhel}" set to "9" (the variable "%{fedora}" in ELN will return "false"), simulating a package build for a future RHEL branch.
ELN will also allow experimentation with the implementation of new ideas without affecting the core Fedora builds. In particular, ELN can be used to test Fedora packages under conditions that apply new compiler flags, disable experimental or unsuitable features for RHEL, modify hardware architecture requirements, and leverage additional CPU extensions. For example, without changing the standard process for building packages in Fedora, one can simultaneously test a build with AVX2 instruction support enabled, and then evaluate the performance impact of using AVX2 in packages to decide on implementing changes in the main Fedora distribution.
Source: opennet.ru
