epel-next-all target alias

[LecrisUT]

• epel-all should not contain any epel-next releases. Afaiu if something is packaged on epel it can also be accessed from centos-stream's epel, but not vice-versa?
• Have a epel-next-all alias for all epel-next targets. Seems weird but who knows when it will come in handy. Might as well be thorough 🤷

[FrostyX]

Hello @LecrisUT,
thank you for the feedback.

Maybe I am missing something but I haven't seen epel-next in the output:

>>> from fedora_distro_aliases import get_distro_aliases
>>> aliases = get_distro_aliases()
>>> [x.namever for x in aliases["epel-all"]]
['epel-7', 'epel-8', 'epel-9']

[LecrisUT]

Probably these need to be added. The releases are available on Bohdi, e.g. epel9-next

[FrostyX]

Ah, I read this sentence

epel-all should not contain any epel-next releases.

as a bug report, i.e. epel-all currently shows epel-next releases and shouldn't be.
But this is rather a RFE - we want to add support for epel-next.

Sounds good to me.

[LecrisUT]

With the recent talk about the future of epel, I think instead it would be helpful to have epel-latest and something to distinguish rhel and centos epel-latest targets.

[carlwgeorge]

Afaiu if something is packaged on epel it can also be accessed from centos-stream's epel, but not vice-versa?

CentOS Stream doesn't have it's own EPEL. EPEL Next is not a complete duplication of EPEL; it only contains select updates that are needed to work with libraries that are different between RHEL and CentOS Stream. So RHEL users consume EPEL, and CentOS Stream users consume both EPEL and EPEL Next together. Maybe that's what you were trying to describe, but I just wanted to be clear on the structure. The EPEL docs go into more detail about EPEL Next.

Have a epel-next-all alias for all epel-next targets.

There were only ever two EPEL Next releases, 8 and 9. EPEL 8 Next has already been retired. There will not be any more EPEL Next releases, because we are moving to a new model with EPEL 10. So epel-next-all will just be equal to EPEL 9 Next, and then after 2027-05-31¹ it will be empty. Therefore I'm not sure it's worth implementing an epel-next-all alias.

Maybe I am missing something but I haven't seen epel-next in the output

This is correct, and is a result of Distro.product only matching the id_prefix of FEDORA-EPEL. If you did decide to include EPEL 9 Next in the epel-all alias, you would just have to modify that condition to also include FEDORA-EPEL-NEXT.

With the recent talk about the future of epel, I think instead it would be helpful to have epel-latest and something to distinguish rhel and centos epel-latest targets.

This came up in rpm-software-management/mock#1427. I like the idea, but I'll need some time to think through what aliases are appropriate, the combinations we'll need to account for over time, and what bodhi properties we can use as indicators. For example, EPEL 10 and 11 are going to overlap, and will have different latest minor versions. I'm also cautious about what we label as development.

Footnotes

1. This is the end of the RHEL 9 "full support" phase, which is also the CentOS Stream 9 and EPEL 9 Next EOL. ↩

[praiskup]

No matter how we name the targets, some fix/change related to the original report will be needed at the time of RHEL 10 GA (when epel-10 is actually equivalent to what epel-9-next was). At least for a Tito users (like me), doing tito release fedora-dist-git frequently using the epel-all and fedora-all aliases. After the RHEL 10 GA event, we are facing a change in tito release expected behavior. What users typically want is to get the released software to users as soon as possible. And going through "next" is typically not needed/wanted, yet that's what the epel-all alias will do for the EPEL 10 variant for RHEL + EPEL users.

[carlwgeorge]

Considering the tito use case you're describing, I can see your point about thinking of epel-all that way. You're right that EPEL Next is typically not needed/wanted. However, it's important not to conflate EPEL Next with what we're doing with EPEL 10.

• In EPEL 9, building against CentOS Stream is optional. The default path is building against RHEL in regular EPEL, which then also gets consumed by CentOS Stream users. Maintainers need to go out of their way to build against CentOS Stream in EPEL Next, because it usually isn't needed.
• In EPEL 10, building against RHEL will be optional. The default path will be building against CentOS Stream for the leading minor version, from the epel10 branch. Maintainers will have to go out of their way to build against RHEL for the trailing minor version.

If the goal is for epel-all to be used as an alias equivalent to "all EPEL users" my recommendation over time would be:

• currently:
  • epel-8
  • epel-9 (not epel-9-next)
• after the EPEL 10 launch:
  • epel-8
  • epel-9
  • epel-10.0
• after the RHEL 10.0 release:
  • epel-8
  • epel-9
  • epel-10.0
  • epel-10.1
• after the RHEL 10.1 release:
  • epel-8
  • epel-9
  • epel-10.1
  • epel-10.2

[praiskup]

Thank you for the feedback, Carl! Very appreciated.

In EPEL 10, building against RHEL will be optional. The default path will be building against CentOS Stream for the leading minor version

Uhh Z-stream process flashback; once we have 10.0 out and the "next" is 10.1 - it is clear that we have to do both builds - that the 10.0 builds are not inherited to next. Or are they?

[carlwgeorge]

once we have 10.0 out and the "next" is 10.1

At this point, builds from the epel10 branch will go to the 10.1 tag and bodhi release.

it is clear that we have to do both builds

That's the way we've been describing and the way it's being documented. It's the same as if you want to release for Rawhide and F41 right now. If a maintainer only does the build from the epel10 branch, then it won't be released for 10.0, and RHEL users won't get it until RHEL reaches 10.1.

that the 10.0 builds are not inherited to next.

10.0 builds done from the epel10 branch prior the the epel10.0 mass branching will be inherited to 10.1. 10.0 builds done after that point (from the epel10.0 branch) will not be inherited to 10.1. This is similar to how things work in Fedora.