epel-release-latest-10 symlink churn, again #117

Closed
opened 2026-08-26 23:59:48 +00:00 by carlwgeorge · 2 comments
Owner

The epel-release-latest links used in our getting started guide are symlinks on the mirror created by the new-updates-sync script. We've had a problem before with this script when it was flipping paths between architectures and causing intermittent 403 errors, and then again later when it was flipping paths between EPEL 10 minor versions. Now we have a new problem, where we legitimately have two different epel-release packages in different EPEL 10 minor versions:

  • EPEL 10.2: epel-release-10-8.el10_2
  • EPEL 10.3/10.4: epel-release-10-9.el10_3

The symlink was churning, but would usually end with the 10.2 path like we wanted. Somehow today it ended up on the 10.4 path, which caused at least one RHEL user to install the wrong release and get dependency errors.

As a short term fix, I have manually switched the epel-release-latest-10.noarch.rpm symlink back to the 10.2 path, and commented out the function call in new-updates-sync script that updates the symlinks.

We should figure out a better long term solution so that we can get the correct behavior.

The epel-release-latest links used in our [getting started guide](https://docs.fedoraproject.org/en-US/epel/getting-started/) are symlinks on the mirror created by the [new-updates-sync script](https://forge.fedoraproject.org/infra/ansible/src/branch/main/roles/bodhi2/backend/files/new-updates-sync). We've had a problem before with this script when it was [flipping paths between architectures and causing intermittent 403 errors](https://forge.fedoraproject.org/infra/tickets/issues/12326), and then again later when it was [flipping paths between EPEL 10 minor versions](https://forge.fedoraproject.org/epel/steering/issues/318). Now we have a new problem, where we legitimately have two different epel-release packages in different EPEL 10 minor versions: * EPEL 10.2: epel-release-10-8.el10_2 * EPEL 10.3/10.4: epel-release-10-9.el10_3 The symlink was churning, but would usually end with the 10.2 path like we wanted. Somehow today it ended up on the 10.4 path, which caused at least one RHEL user to [install the wrong release](https://bugzilla.redhat.com/show_bug.cgi?id=2521652) and get dependency errors. As a short term fix, I have manually switched the epel-release-latest-10.noarch.rpm symlink back to the 10.2 path, and commented out the function call in new-updates-sync script that updates the symlinks. We should figure out a better long term solution so that we can get the correct behavior.
Author
Owner
https://forge.fedoraproject.org/infra/ansible/pulls/3642
Author
Owner

That PR has been merged and deployed, and everything seems to be working as expected.

That PR has been merged and deployed, and everything seems to be working as expected.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
epel/releng#117
No description provided.