This is not reproducible from EPEL 10.2 on RHEL 10.2, using the standard epel-release package.  Why are you trying to use EPEL 10.3 on Rocky 10.2?  How did you enable EPEL?

Thanks.  OK, this behavior either escaped me in the past or was a recent change.  I thought specifying /10 would bring in packages for the latest epel release (10.2).  It appears that behavior instead brings in packages for the next release (10.3).  My reposync was set to https://mirrors.vcea.wsu.edu/epel/10/ instead of https://mirrors.vcea.wsu.edu/epel/10.2/.  Changing it to the latter (probably) fixes the issue.  Has this behavior always been the case?  It seems backwards and wrong to me.  The end-user should just be able to bring in /10 and expect to get the latest RELEASED packages and not the "test" packages for future versions, because then said user doesn't need to update the url they sync from when the next version of el10 is release.

EPEL 10 (launched in December 2024) indeed introduced minor versions.

https://communityblog.fedoraproject.org/epel-10-is-now-available/

Facilitating this required a few changes in the infrastructure.  The default metalinks in epel-release will point you to the appropriate minor version, currently 10.3 if you're using CentOS 10, and 10.2 if you're using RHEL 10 or a rebuild.  epel-release also has commented out baseurls as examples for people who want to pin to specific mirrors.  The implementation keys off whether the releasever_minor DNF variable is set, with basic bash-style variable expansion.

#baseurl=https://download.example/pub/epel/$releasever${releasever_minor:+z}/Everything/$basearch/
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel${releasever_minor:+-z}-$releasever&arch=$basearch

On RHEL (or a rebuild) where releasever_minor is set, the metalink uses the epel-z-10 repo name, and the baseurl uses the epel/10z path.  On CentOS where it isn't set, the metalink uses the epel-10 repo name, and the baseurl uses the epel/10 path.

If you're going to mirror EPEL content I highly recommend utilizing the example baseurl pattern from epel-release.

Thanks, Carl.  I really appreciate the explanation.  I still think the behavior of pushing packages to "${releasever}/" that are intended for a future, unreleased version is incorrect: it should be pushed to "testing/${releasever}/" or equivalent.  However, if by configuration "${releasever}/" is ultimately just a symlink to the latest, unreleased minor version ("10.3/" in this case), then there's nothing I can do.

I use Katello for mirroring and must be explicit about the upstream URL; so using a variable like "releasever_minor" isn't possible.  That's not your problem though :)

For now, it looks like I can set my upstream url to "10z/" and get the un-upgraded version of python3-pyOpenSSL without having to specify a minor version though I'm sure that opens a whole other can of worms.  Why does the zed branch have v25.0 python3-pyOpenSSL, but the "${releasever}/" branch has v26.0?

FEDORA-EPEL-2026-91831c24d9 (pyOpenSSL-26.3.0-1.el10_3) has been submitted as an update to Fedora EPEL 10.3.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-91831c24d9

FEDORA-EPEL-2026-91831c24d9 has been pushed to the Fedora EPEL 10.3 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-91831c24d9

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Carl provided some helpful guidance at https://bugzilla.redhat.com/show_bug.cgi?id=2494597#c5 for all whose private EPEL 10 mirrors stopped working recently.

Thanks, Daniel.  Thanks to Carl's explanation in https://bugzilla.redhat.com/show_bug.cgi?id=2494597#c5 it's clear that /10z should be used.  Closing.

FEDORA-EPEL-2026-91831c24d9 (pyOpenSSL-26.3.0-1.el10_3) has been pushed to the Fedora EPEL 10.3 stable repository.
If problem still persists, please make note of it in this bug report.

OS version is RHEL 10.2.  epel-release on my system was just upgraded from epel-release-10-8.el10_2.noarch to epel-release-10-9.el10_3.noarch.  I have python3-pyOpenSSL-26.3.0-1.el10_3 available as an update.  I get the following error.

Error:
 Problem: cannot install the best update candidate for package python3-pyOpenSSL-25.0.0-1.el10_1.noarch
  - nothing provides (python3.12dist(cryptography) < 50~~ with python3.12dist(cryptography) >= 49) needed by python3-pyOpenSSL-26.3.0-1.el10_3.noarch from epel

This is still a problem. When will it be resolved.


# LANG=C dnf update
Updating Subscription Management repositories.

This system has release set to 10 and it receives updates only for this release.

Last metadata expiration check: 0:10:24 ago on Wed Oct 14 09:35:22 2026.
Error: 
 Problem: cannot install the best update candidate for package python3-pyOpenSSL-25.0.0-1.el10_1.noarch
  - nothing provides (python3.12dist(cryptography) < 50~~ with python3.12dist(cryptography) >= 49) needed by python3-pyOpenSSL-26.3.0-1.el10_3.noarch from c221d2aa-c5a1-4e2f-863c-f3e04e06756c
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)


# rpm -q epel-release-10
epel-release-10-9.el10_3.noarch

Mikkel, if you're seeing that error you are likely using RHEL 10.2 with EPEL 10.3.  Others in this bug observed this behavior by setting up a custom local repo with an incorrectly configured mirror.  If you're seeing the same behavior with epel-release, then you someone got the 10.3 update early.  I suggest manually installing the epel-release for 10.2 and merging in any rpmnew files in /etc/yum.repos.d.

    dnf install https://dl.fedoraproject.org/pub/epel/10.2/Everything/x86_64/Packages/e/epel-release-10-8.el10_2.noarch.rpm

It is stil not working.

I just added to /etc/dnf/dnf.conf and that works

[main]
...
exclude=python3-pyOpenSSL