The original EPEL 10 proposal thread is getting a bit long, so I’d like to start a new thread to specifically focus further discussion on just one aspect: the best way to point users at the correct minor-versioned repo.
In the original proposal, I suggested making use of symlinks on the infrastructure side that move to point at different repos at different times. This would require different epel-release packages for CentOS and RHEL that point to the appropriate symlinks. (Note: this approach will require changes to MirrorManager to no longer ignore symlinks).
RHEL and RHEL clone users:
epel-release-rhel package
epel.repo file with repo=$releasever metalink
mirrormanager redirecting to $releasever (10) symlink on various mirrors
CentOS Stream users:
epel-release-centos package
epel.repo file with repo=centos$releasever metalink
mirrormanager redirecting to centos$releasever (centos10) symlink on various mirrors
This approach also has an additional benefit that users could temporarily override $releasever to select a specific minor version repo to install from, either older or newer (e.g. dnf --releasever 10.2 install foo).
It was also suggested by @ngompa that if dnf5 implements a feature request for major/minor version variables, we could use those to avoid the need to change symlinks for RHEL. The RHEL epel.repo file would use repo=$releasever_major.$releasever_minor to ask MirrorManager for the appropriate EPEL repo matching the current RHEL release. It’s not clear to me how we would handle the CentOS epel.repo file with this approach. CentOS Stream doesn’t advertise what minor version it currently represents. Would we still need a symlink for CentOS anyways? Would it be better to rename the leading repo directory to just 10 and rely on $releasever?
The behavior Zypper has is that if the distribution doesn’t have a minor version, then $releasever_minor is empty. Zypper also supports limited variable expansion capabilities for this purpose, so something like repo=${releasever_major}${releasever_minor:+.${releasever_minor}} would work.
This would allow us to use a single repo file for both Stream and RHEL, assuming that we always have minor versions for the EPEL tree used for RHEL and derivatives.
The idea would be to have this functionality ported over to DNF5 and leverage it.
This is intriguing to me, and sounds like it could work. But I’m worried for a few reasons.
These capabilities don’t exist yet, and the dnf5 team already have plenty of work in front of them to bring dnf5 to feature parity with dnf in time for EL10 without worrying about new features.
Asking for major/minor variables is one level of complexity. Asking for pseudo-shell expansion capabilities is another level on top of that. Even if we can get the first done in time, I have doubts for the second.
These features were first requested back in January 2020, even predating the announcement of dnf5. There has been zero comments on the bugzilla request from the development team, and I’m not aware of any other public indication that they’re even considering this feature.
Perhaps the way to address this would be to call this our preferred solutions, but contingent on the features existing by some agreed upon date. If the features aren’t implemented in time, then we move forward with an alternate plan (symlinks probably, or something else).
Another possibility has been suggested on the epel-devel mailing list by @tdawson. We could try to use RPM file triggers to fire off a scriptlet from epel-release that creates /etc/dnf/vars/epelrelease based on the value of VERSION_ID in /etc/os-release. It would be run every time /etc/os-release gets updated, changing the value of the epelrelease variable to match the OS. This would solve things neatly for RHEL, but I’m not clear yet on how it would work for CentOS Stream. Its has a VERSION_ID of just the major version. I suppose this is another scenario that would be well served by having the leading repo directory be just 10, instead of 10.minor.