TASK: EPEL 10 CR config?

[yselkowitz]

What does the ELN SIG need to do?

Would it make sense to create an EPEL 10 add-on view to Content Resolver, using c10s as a base? It should help detect when packages are or become uninstallable due to missing or changed dependencies, among other things.

To start, most Extras configs would be labelled both epel10 and eln-extras, just like most RHEL configs are currently both c10s and eln. As ELN diverges from c10s and gets closer to becoming c11s, then we would presumably see some divergence in EPEL vs ELN Extras as well.

Possible reasons against would be 1) CR resources and 2) EPEL 10's lifespan is much longer than c10s', and we weren't sure how long we should keep c10s around for either.

One major caveat is that CR does not currently handle build dependencies for addon configs (#194).

/cc @carlwgeorge

[carlwgeorge]

#194 seems like a huge flaw for ELN Extras, and I would consider it a blocker for adding any more addon CR configs. And honestly, with EPEL 10 getting started, I question the value that an EPEL 10 CR config could provide at this point anyways. It makes sense for c10 to ensure that changing workloads and dependencies don't pull in too many more packages, but that is only a priority for eln/c10/rhel10, not epel10. EPEL is all about shipping additional content, which is a contrary goal for CR in the first place.

Instead of this, I would much rather see effort directed into fixing #194, improving CR onboarding docs, improving CR itself (especially the UI/UX), and working with EPEL maintainers to get their workloads into ELN Extras in preparation for EPEL 11. IMO, the window for CR to have a noticeable impact on EPEL 10 has closed, and we need to look towards the future instead.