On Fri, Jun 27, 2025 at 9:29 PM Chris Adams <li...@cmadams.net> wrote: > > Once upon a time, Carl George <c...@redhat.com> said: > > There is a high level overview of EPEL 10 branches in the documentation. > > > > https://docs.fedoraproject.org/en-US/epel/branches/#_epel_10 > > > > If you prefer video to written documentation, check out this > > presentation I gave at CentOS Connect earlier this year. > > > > https://youtu.be/3pbjS-tD4q8 > > > > For a longer background, see this discussion thread of the initial > > EPEL 10 proposal. > > > > https://discussion.fedoraproject.org/t/epel-10-proposal/44304 > > > > epel10.0 branches were created automatically for all packages with an > > existing epel10 branch during a mass branching event that took place > > back in February. > > > > https://pagure.io/epel/issue/304 > > > > If you have a package that didn't have an epel10 branch before the > > mass branching, you can manually request an epel10.0 branch with > > fedpkg request-branch, just like you would request an f42 branch for a > > new package that only has a rawhide branch and missed the f42 mass > > branching. We've intentionally set up EPEL 10 to have similarities to > > both RHEL and Fedora branching so that it is a more intuitive > > experience for maintainers. That said, it's still a change from how > > EPEL has traditionally worked, so I hope the references I've provided > > here help the transition make more sense for you. > > I think it's weird that requesting a branch for epel10 lands in epel10.1 > right now, rather than the current RHEL release of 10.0. This means > that I requested a bunch of packages to be branched for epel10 and none > of them are available on a released version. I guess I can go reopen > the BZes to ask for maintainers to also create epel10.0 branches (that > feels a bit extra).
If a RHEL maintainer is adding a new package, it also lands in 10.1, not 10.0. They can request 10.0 if needed. For your EPEL 10 package requests, you can re-open the previous bugs, file new bugs, or just going forward mention that you are requesting the package for both 10.0 and 10.1. Or just live with the new packages being set up for 10.1 only and wait a few months to deploy them on RHEL 10.1. > IMHO epel10 should be the current release, with some other branch > representing the "rawhide" equivalent (I'd say epel10next but don't want > to confuse with ELN). That is somewhat how epel9 and epel9-next worked. It was confusing and inefficient. EPEL 10's minor version structure is specifically designed to fix this and give maintainers a more intuitive workflow. Regardless, we (the EPEL Steering Committee) started planning EPEL 10 over two and a half years ago. I'm sorry, but the time to suggest major changes to the structure was back then, not now after we've already implemented it. https://discussion.fedoraproject.org/t/epel-10-proposal/44304 > At a minimum, the "request a package for EPEL" should be updated to > specify that you need to ask for at least two branches, epel10 and > epel10.<current>. But not everyone does. Anyone consuming EPEL 10 from CentOS 10 or Alma Kitten 10 doesn't. Many RHEL users plan further ahead and are fine with requesting something now and waiting a few months to start consuming it. Some of them have been following along with the EPEL 10 planning, and requested the packages they wanted to use on RHEL 10.0 back before the epel10.0 mass branching in February. That said, I think updating the request guide with a note about _optionally_ asking for multiple branches is a good idea. Could you send a pull request for that with the wording you had in mind? https://pagure.io/epel/blob/main/f/modules/ROOT/pages/epel-package-request.adoc > Also, one of the suggested work-arounds for this was: > > # dnf --releasever 10.1 install foo > > But that doesn't work because that sets it globally and breaks the RHEL > repos. And if you just enable the EPEL repos, you can't install > something that has a dependency on a RHEL package. So I don't see any > good way to install a new epel10 build other than edit the EPEL yum repo > files to replace $releasever_minor with a hard-coded value (and then > remember to undo it later). > > -- > Chris Adams <li...@cmadams.net> > -- > _______________________________________________ > 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 > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Carl George -- _______________________________________________ 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 Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
