On Wed, Sep 09, 2020 at 01:15:29PM -0500, Carl George wrote: > > 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.
Changing the dist tag is pretty easy (can be done in koji)... % rpmdev-vercmp 1.0-1.el8 1.0-1.epel8stream 1.0-1.el8 < 1.0-1.epel8stream Might also make it easier to see where packages came from? > > 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. ok. I'm not sure it's a problem per se, but something to note. > > 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. > ok. Thats a non trivial amount of work added on. (creating bodhi release for it, updating sync scripts and punji config, etc). Can be done, but will definitely be more work. kevin
signature.asc
Description: PGP signature
_______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
