Howdy again folks, I know people have been curious about what happened with this proposal. I apologize for the lack of updates in this thread. The proposal was approved by unanimous vote by the EPEL Steering Committee last October [0]. It has been a regular topic at the weekly committee meetings since then, with slow but steady progress. I'm happy to report that we are near completion of the work to launch EPEL Next. Initial documentation is on the wiki [1]. Fedpkg 1.40-6 [2] added support for requesting epel8-next branches, and has been widely available since April. The epel-next-release subpackage is currently available in the testing repo [3]. There is already one package available in the repo (qt5-qtwebkit [4]), which we used to verify the pipeline worked correctly. Let me know if there is anything else you would like to see in the documentation, especially FAQ items [5]. I would also appreciate any testing and karma on the epel-next-release bodhi update [2]. If you have a package that requires an EPEL Next rebuild (mainly qt packages currently), go ahead and try the workflow [6] and report any issues. [0] https://meetbot.fedoraproject.org/teams/epel/epel.2020-10-23-21.01.html [1] https://fedoraproject.org/wiki/EPEL_Next [2] https://src.fedoraproject.org/rpms/fedpkg/c/ee2d8465803e11c236ae764d445b99593d835353?branch=rawhide [3] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2021-159d68a2ef [4] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2021-c0fcb78eb0 [5] https://fedoraproject.org/wiki/EPEL_Next#FAQ [6] https://fedoraproject.org/wiki/EPEL_Next#Example_Workflow On Tue, Sep 8, 2020 at 11:00 PM Carl George <carl@xxxxxxxxxx> wrote: > > 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 -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
