EPEL 10 vs. 10.1

[Chris Adams]

With the release of RHEL 10 (10.0), I started working on some system
setups.  I requested some EPEL 10 branches of a few packages (thanks to
all maintainers!)... but then don't see the packages on a RHEL 10
system.  I think it's because they made epel10 branches, which are now
going to 10.1 rather than 10.0.

How is this supposed to work?  Is there a way to request 10.0 branches
(would I need to go back to all the maintainers)?  Is there a way to
pull in the 10.1 RPMS other than just hard-coding the minor version in
/etc/yum.repos.d/epel.repo?

I can't seem to find the docs about the EPEL 10 releaes plans with the
point releases.

[Carl George]

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.

On Tue, Jun 17, 2025 at 8:40 PM Chris Adams  wrote:
> With the release of RHEL 10 (10.0), I started working on some system
> setups.  I requested some EPEL 10 branches of a few packages (thanks to
> all maintainers!)... but then don't see the packages on a RHEL 10
> system.  I think it's because they made epel10 branches, which are now
> going to 10.1 rather than 10.0.
>
> How is this supposed to work?  Is there a way to request 10.0 branches
> (would I need to go back to all the maintainers)?  Is there a way to
> pull in the 10.1 RPMS other than just hard-coding the minor version in
> /etc/yum.repos.d/epel.repo?
>
> I can't seem to find the docs about the EPEL 10 releaes plans with the
> point releases.
>
> --
> Chris Adams 
> --
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Chris Adams]

Once upon a time, Carl George  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).

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

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

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

[Carl George]

On Fri, Jun 27, 2025 at 9:29 PM Chris Adams  wrote:
> Once upon a time, Carl George  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.a...
> 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 
> --
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue