Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Package conflict on el10 when attempting to update to the latest version python3-pyOpenSSL-26.2.0-2.el10_3.noarch ``` Error: Problem: cannot install the best update candidate for package python3-pyOpenSSL-25.0.0-1.el10_1.noarch - nothing provides (python3.12dist(cryptography) < 49~~ with python3.12dist(cryptography) >= 46) needed by python3-pyOpenSSL-26.2.0-2.el10_3.noarch from <redacted_epel> (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) ``` Version-Release number of selected component (if applicable): 26.2.0-2.el10_3 How reproducible: Always Steps to Reproduce: 1. dnf update python3-pyOpenSSL Actual results: Fails to update to 26.2.0-2.el10_3 Expected results: Update to 26.2.0-2.el10_3 Additional info: $ cat /etc/redhat-release Rocky Linux release 10.2 (Red Quartz) $ uname -a Linux <redacted> 6.12.0-211.22.1.el10_2.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Jun 11 19:07:13 UTC 2026 x86_64 GNU/Linux
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