[EPEL-devel] Re: Bug in epel-release yum config, or in redhat-release package?
On Wed, Nov 12, 2025 at 9:02 PM Carl George wrote: > > On Wed, Nov 12, 2025 at 7:21 PM Gordon Messmer > 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]
[EPEL-devel] Re: Bug in epel-release yum config, or in redhat-release package?
On Wed, Nov 12, 2025 at 7:21 PM Gordon Messmer 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
[EPEL-devel] Re: Bug in epel-release yum config, or in redhat-release package?
On Wed, Nov 12, 2025 at 8:20 PM Gordon Messmer 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
[EPEL-devel] Re: Bug in epel-release yum config, or in redhat-release package?
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. 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. -- ___ 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
[EPEL-devel] Re: Bug in epel-release yum config, or in redhat-release package?
On Wed, Nov 12, 2025 at 6:34 PM Gordon Messmer wrote:
>
> On 2025-11-12 2:56 PM, Neal Gompa wrote:
> > We tried. If the package provided the full releasever, a lot of things
> > would have been simpler, but there were arguments that some Red Hat
> > tooling couldn't handle it currently.
>
>
> OK. Then, can the epel repo configs do the ugly but reliable thing?
> metalink is set up to provide a URL to the correct places, when clients
> ask for it.
>
>
> I don't know if this is the simplest expression, but it results in 10.0
> systems getting packages built for 10.0 (and remains compatible with
> CentOS Stream):
>
> metalink=https://mirrors.fedoraproject.org/metalink?repo=epel${releasever_minor:+-z}-$releasever${releasever_minor:+.}$releasever_minor&arch=$basearch
>
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.
--
真実はいつも一つ！/ 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
[EPEL-devel] Re: Bug in epel-release yum config, or in redhat-release package?
On 2025-11-12 2:56 PM, Neal Gompa wrote:
We tried. If the package provided the full releasever, a lot of things
would have been simpler, but there were arguments that some Red Hat
tooling couldn't handle it currently.
OK. Then, can the epel repo configs do the ugly but reliable thing?
metalink is set up to provide a URL to the correct places, when clients
ask for it.
I don't know if this is the simplest expression, but it results in 10.0
systems getting packages built for 10.0 (and remains compatible with
CentOS Stream):
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel${releasever_minor:+-z}-$releasever${releasever_minor:+.}$releasever_minor&arch=$basearch
--
___
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
[EPEL-devel] Re: Bug in epel-release yum config, or in redhat-release package?
On Wed, Nov 12, 2025 at 5:37 PM Gordon Messmer wrote: > > On UBI 10.0, the EPEL repo configuration will provide packages built for > 10.1. I don't know if that's a bug in the repo definition, or in the > redhat-release package, but it seems like it must be one of the two. > This is broken as intended. If you want to use 10.0 EPEL content, you'll need to do it manually. > > So, I'd think that either the redhat-release package should provide > "system-release(releasever) = 10.0", or the epel repo definition should > detect and append the minor version in the URL (but that seems really > really ugly). > We tried. If the package provided the full releasever, a lot of things would have been simpler, but there were arguments that some Red Hat tooling couldn't handle it currently. -- 真実はいつも一つ！/ 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
