On Wed, Nov 12, 2025 at 8:20 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. >
We do not support EUS at all. People using EPEL with EUS should ask Red Hat to support them with the Extensions repo or something else with paid resources. Making the community do it for people who are willing to pay Red Hat for extra support is unfair in my book. > 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/) > > 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. 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. > It would be broken at the minimum for anyone with KDE Plasma because every RHEL minor has a Qt upgrade. OpenSSL and other things happen from time to time, but KDE Plasma is *guaranteed*. That means that it would block updates and users would be in an ugly mess to figure out how to reconcile it. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ 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
