> 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). Yes, I believe dnf helps us out here as you described. We could also document that packagers should take care to ensure the upgrade path works from epel8 to epel8-next, similar to Fedora branches. Fedora has the added benefit of the dist macro always ensuring the release field is higher on higher branches, but in our cases it's .el8 for both. Maybe we could consider redefining dist for epel8-next builds to accomplish the same thing, but I'm not sure it's worth the effort. > 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? Yes, but I don't see a problem with this. > 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? My preference would be to use bodhi updates. I think updates getting published without review would degrade the experience for CentOS Stream users. We could do a lower karma/time threashold than regular EPEL if desired. On Wed, Sep 9, 2020 at 11:55 AM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > 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 > _______________________________________________ > 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 -- 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
