On Wed, Nov 12, 2025 at 9:02 PM Carl George <[email protected]> wrote: > > 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`.
I need to correct myself here. It occurred to me that RHEL 10 EUS actually exists now, so I went to verify. `subscription-manager release --set` doesn't actually change releasever, it just replaces instances of `$releasever` in redhat.repo with the string you give it, e.g. 10.0. So if you want to use EPEL 10.0 on RHEL 10.0 EUS, you'll need to write 10.0 to `/etc/dnf/vars/releasever` in addition to the normal steps to enable EUS. > > 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 -- 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
