Howdy folks, A large part of my day job is working on CentOS Stream. Naturally I would like it to be successful and have wide adoption. I know that EPEL will play a big role in this success. EPEL is extremely popular. Many users consider RHEL and CentOS unusable without it. The problem we are facing is that EPEL 8 cannot be 100% compatible with RHEL/CentOS 8 and CentOS 8 Stream at the same time. It is not uncommon for RHEL to ship library soname changes in minor releases. In the RHEL 8 cycle, those changes are showing up in CentOS 8 Stream first. EPEL 8 builds against the latest RHEL 8 release. This can result in EPEL 8 packages that are uninstallable on CentOS 8 Stream due to the library differences. One prominent example we have already seen is llvm-libs, which has increased its library soname in every RHEL 8 minor release so far. Another increase is planned for RHEL 8.3, which has already been released in CentOS 8 Stream. There are likely other incompatibilities that haven't been noticed yet. I expect this problem to grow worse as RHEL development continues and more packages are added to EPEL 8. This situation is hurting the adoption of CentOS Stream. To solve this problem, I am proposing that we create a new repository called EPEL 8 Next. - built against CentOS 8 Stream - opt-in for packagers (must request epel8-next dist-git branch) - opt-in for users (part of epel-release but disabled by default) - used *with* epel8, not *instead of* This will provide EPEL packagers a place where they can update their packages when necessary to be compatible with CentOS 8 Stream. These packages would also be useful for RHEL 8 users during the gap between a RHEL minor release and the equivalent CentOS 8 Linux rebuild. In theory this repository should also be directly consumable by RHEL 8 Beta releases. Similar to RHEL itself, breaking changes could be permitted in epel8-next in preparation for delivering them to epel8 around the time of the next RHEL minor release. This proposal may sound similar to epel8-playground. However, that was still built against RHEL 8, so it didn't solve the compatibility issue with CentOS 8 Stream. This proposal does draw on lessons learned from the playground experiment. - no automatic builds via packages.cfg - opt-in rather than opt-out - layering on top of epel8, rather than duplicating content I first suggested this idea at the last EPEL Steering Committee meeting, and we plan to discuss it again during the next one. Please share your thoughts on this proposal. -- Carl George _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
