Hi All,
EPEL2RHEL is part of the RHEL 8 and 9 new package workflow. When a RHEL maintainer wants to add a package to RHEL 8 or 9 they start a "new package workflow". There are several automations that happen when they start that workflow. One of them is checking if the package is already in epel. If it is, it creates a bugzilla against that package, and links that bug against the EPEL2RHEL tracker. [1]
Remember, this check currently happens at the beginning of the new package workflow. Before a package has been branched, built, or put into testing repos.
Thus far, there are three problems.
1 - The wording can be confusing:
Subject: Remove <package> from epel9
Comment: This package is being added to RHEL 9.1 at the next minor release. Please remove it from epel after the next RHEL minor release.
The subject sounds like it should be removed right now. Only if the maintainer reads the comments do they see it should be removed after the next release.
What is further confusing is if the package is coming out for a release that has already happened. We just had one that said it was being added to RHEL 8.6. The instructions clearly state that it should be removed after RHEL 8.6 is released, and so it was removed.
2 - What about BuildRoot only packages.
If a RHEL package is a BuildRoot only package, they are fine being in epel. But at the time the new package is requested, the scripts have no way of knowing where the binary packages will end up.
Thus, it is possible that a package creates an EPEL2RHEL bug, that package ends up being in RHEL BuildRoot only, and the epel maintainer removed the package anyway.
3 - Race conditions
We already saw in RHEL 8.6 that race conditions exist. There were two packages that were requested in epel and RHEL on the same week. Both checked, didn't see anything, and then went along their proper path. Only to find out that when RHEL 8.6 was released, we had duplicate packages in epel8.
** Solution(s)
A - At the very least, we need to change the wording of the bugs. I am proposing the following
Subject: Remove <package> from epel9 when rhel 9.1 is released
Comment: This package is being added to RHEL 9.1 at the next minor release. After the next RHEL minor release, please verify this package was released in RHEL, and if so remove it from epel9.
B - If possible, move the EPEL2RHEL check to later in the development cycle. I would like it to be in the step where the packages get added to BaseOS, AppStream, or CRB. That way we would know it isn't going to be a BuildRoot only package, and it would reduce the time the bugs sit waiting.
I don't know if this is possible, but I'm going to ask.
C - ?? What if we only created the bugs on the tracker itself, and not the individual packages ??
Would that be a good thing? Or would it irritate the maintainers?
Troy