On Wed, Nov 12, 2025 at 7:21 PM Gordon Messmer <[email protected]> wrote: > > On 2025-11-12 4:28 PM, Neal Gompa wrote: > > No, we can't, because the default for RHEL-ish platforms is a rolling > > major content stream. That means that the upgrade path is broken > > without the releasever thing. Without some way to update the value of > > $releasever as*part* of the upgrade transaction, it would be broken. > > We didn't have time to implement a mechanism for RHEL 10, but it might > > be solvable for RHEL 11. > > > I don't have any EUS licenses to test, but doesn't this mean that EPEL > isn't configured to support EUS systems, by default? It looks like > they'd get EPEL content for the wrong minor release.
RHEL EUS should work out of the box. Enabling EUS involves switching to the EUS repos and running a command like `subscription-manager release --set 10.0`, after which point releasever will be set to 10.0 and the default epel-release metalink will direct that system to the matching EPEL minor version, e.g. `epel-z-10.0`. https://access.redhat.com/articles/rhel-eus That said, the EPEL Steering Committee has explicitly declined to keep EPEL minor branches open to correspond with EUS, so EUS users won't be getting updates for their EPEL content. But they should continue to have an EPEL 10.0 repo served from the archive that works as well as it does on the day it's retired, which is a massive improvement over how things worked in earlier EPEL major versions. > > I don't know if supporting "RHEL-ish" non-RHEL platforms is a priority, > but during the gap between the release of a new RHEL minor and a > RHEL-ish minor, those systems will be offered content for the wrong > minor release, which may fail (e.g.: > https://www.reddit.com/r/AlmaLinux/comments/1ouygdn/issue_related_to_openssl_library_when_updating/) The delay between RHEL and RHEL rebuilds has always been a headache. Early on in the planning for EPEL 10 we thought we could solve this by having systems always ask for an EPEL minor version matching their OS minor version, but we discovered handling it this way would cause upgrade path issues. https://pagure.io/epel/issue/324 Jonathan Wright from Alma in on the EPEL Steering Committee and participated in the related discussion during meetings. His input was he would rather Alma systems be temporarily broken during the rebuild gap instead of being broken until manual intervention took place, something that would be especially problematic for systems using dnf-automatic. > > It's possible that this could cause serious problems on RHEL systems, > though... If I have a RHEL 10.0 system with EPEL, and I run "dnf install > python3.13", it will pull an openssl-libs update along with it, because > openssl uses versioned symbols. But openssl requires libz, and libz does > *not* provide versioned symbols. > > Hypothetically, if RHEL 10.1 had rebased both openssl and libz, that > process might result in updating openssl to support python3.13, but not > updating libz, which could cause runtime linking failures with > everything linked to openssl. > > ( I hope we fix that someday: > https://github.com/rpm-software-management/rpm/pull/2372 ) > > If the epel repo definition included the current minor, it's true that > users would need to do two updates to fully update a system to a new > minor. They'd get new platform packages with "dnf update" and then get > new EPEL packages with a second "dnf update". That's not great. Indeed, that is the scenario we identified in the issue I linked above, which we decided against due to the dnf-automatic scenario. > But I > think it would fix problems with RHEL-ish systems during their update > delay, fix problems with EUS systems (that I think exist, but haven't > verified), and avoid potential problems with "dnf install xxx" on a RHEL > system that hasn't updated to the newest minor release yet. > > -- > _______________________________________________ > epel-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Carl George -- _______________________________________________ epel-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
