Description of problem: EPEL 8 contains the $releasever variable in the baseurl. The only valid setting is 8 so we don't need a variable here. Any customers that set the releasver using "--releasever" or with "/etc/yum/vars/releasever" will encounter a 404 unless they set to 8, which affects Azure or RHUI customers. Version-Release number of selected component (if applicable): How reproducible: Everytime Steps to Reproduce: 1. # yum repolist --enablerepo=epel --releasever=8.4 2. 3. Actual results: - Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-8.4&arch=x86_64&infra=$infra&content=$contentdir (IP: 209.132.190.2) Error: Failed to download metadata for repo 'epel': Cannot prepare internal mirrorlist: Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=epel-8.4&arch=x86_64&infra=$infra&content=$contentdir (IP: 209.132.190.2) Expected results: Remove the "$releasever" variable and customers can always access the EPEL content. Additional info: Discussed here https://access.redhat.com/discussions/5473561 Workaround: # sed -i 's/$releasever/8/g' /etc/yum.repos.d/epel.repo
Moving to the epel-release component: $ rpm -qp https://iad.mirror.rackspace.com/epel/epel-release-latest-8.noarch.rpm --qf "%{SOURCERPM}\n" epel-release-8-10.el8.src.rpm
Filed a PR upstream replacing $releasever with 8. https://src.fedoraproject.org/rpms/epel-release/pull-request/14
Yeah, thats the simple fix... but now that we are snapshotting/archiving epel at minor rhel releases, perhaps we should teach mirrormanager about the minor releases? That would let people use the archived versions easier, but also would mean that people on say 8.3 would stay on the archived epel until they upgraded to 8.4 so they may not be aware that they are not getting updates. Should discuss more. Please don't merge the pr yet.
(In reply to Kevin Fenzi from comment #3) > Yeah, thats the simple fix... but now that we are snapshotting/archiving > epel at minor rhel releases, perhaps we should teach mirrormanager about the > minor releases? Interesting! /me Didn't know that was an ongoing discussion. > That would let people use the archived versions easier, but also would mean > that people on say 8.3 would stay on the archived epel until they upgraded > to 8.4 so they may not be aware that they are not getting updates. > > Should discuss more. Please don't merge the pr yet. No worries. I'll consider this notice to hold tight. If there is any further assistance I can offer, feel free to let me know!
Adding Adrian here for comment. Can we adjust mirrormanager here to accept 8.x and redirect 8.1, 8.2, 8.3, to archive snapshots and 8.4 or 8 to current? But that does have the downside that those people going to snapshots will never ever get updates and they may not realize it.
I am concerned about people not getting their updates. Can we go the other way, and have 8.{1,2,3,4..} redirect to 8 ?
(In reply to Kevin Fenzi from comment #5) > Adding Adrian here for comment. > > Can we adjust mirrormanager here to accept 8.x and redirect 8.1, 8.2, 8.3, > to archive snapshots and 8.4 or 8 to current? > > But that does have the downside that those people going to snapshots will > never ever get updates and they may not realize it. This is complicated from MirrorManager's side. We do not scan the archive currently for new repositories, because we had problems before that we picked up really old and deprecated stuff. So currently it is difficult to create repositories for the archived 8.x content. But only because we never did it before. This would be somehow fixable. Not nice, but fixable. MirrorManager cannot handle repository names based on wildcards or regex. We can, however, create manual repository redirects. So if someone would ask for 'epel-8.4' we could add an entry to the database to point to 'epel-8'. That is, however, a manual step currently. For something like this I would recommend a webserver level redirect/rewrite like we did at some point for '7Server' to '7'.
The EPEL ecosystem is important to Red Hat's supported RHEL customer base. Could we please implement the interim workaround of hardcoding "8" for now, and then implement your long term desired solution after the other required changes are implemented? We have been providing a broken user experience for a very long time now. thank you.
I agree with Terry's sentiment. Let's change this now, and when (or if) we get the infrastructure to be able to handle a variable, we change it back to the variable.
FEDORA-EPEL-2022-9c9fab6933 has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-9c9fab6933
FEDORA-EPEL-2022-9c9fab6933 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-9c9fab6933 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2022-9c9fab6933 has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Kevin Fenzi from comment #3) > now that we are snapshotting/archiving > epel at minor rhel releases Really? Where can I find these archived minor releases? I.e. I don't see anything at https://dl.fedoraproject.org/pub/epel/ reflecting that.
https://dl.fedoraproject.org/pub/archive/epel/