On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George 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) I like tdawsons idea down thread that it be a 'epel-release-stream' or whatever subpackage, so they have to install that and enable it (just like they would for enabling stream) > - used *with* epel8, not *instead of* So, maintainers would need to be careful to make sure epel8-next or whatever packages are rpm 'newer' at all times to make this work right? Or I guess if they were fixing soname issues like above, dnf might be smart enough to pull in the next version anyhow even if it was lower than the epel8 one (unless the user used --best). Possibly it would be best to say 'must be newer' and have some kind of check... ? > 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. So, say I have package foo that needs a rebuild to work with stream. I request a branch, do a build and everything there is happy. Now, 8.x comes out and the main epel8 one needs a rebuild. I do that and push it out and everything is happy again... but what about the epel8-stream/next package? It just sits there older and unused? > > 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. I assume this would work like playground/rawhide as far as landing in the buildroot right after build and going out in the daily compose? Or would you want to use bodhi updates? kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ 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
