epel-release-latest-10 symlink churn, again #117
Labels
No labels
backlog status
needs review
backlog status
ready
chore
documentation
planned
points
01
points
02
points
03
points
05
points
08
points
13
priority
high
priority
low
priority
medium
sprint status
blocked
sprint status
done
sprint status
in progress
sprint status
review
sprint status
to do
technical debt
work item
bug
work item
epic
work item
spike
work item
task
work item
user story
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
epel/releng#117
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:
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.
infra/ansible#3642
That PR has been merged and deployed, and everything seems to be working as expected.