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
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
