On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote:
At the EPEL Steering Committee last week, we had an extensive
discussion of
this proposal, specifically focused on how to handle the dist macro. I
believe these are the possible choices.
* keep dist the same as epel8 (.el8)
RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently using .el8 for
dist. It would make sense to continue using the same dist for EPEL Next.
However, this would put a little more work on packagers. They would not be
able to build the same commit for both EPEL and EPEL Next because the NVR
will conflict in Koji. In simple rebuild situations, this is not a problem
because at a minimum the release will be higher. But if a packager wanted
to update the package in both EPEL and EPEL Next, they will need to first
update and build it in EPEL, then bump the release and build it in EPEL
Next. This isn't ideal, but isn't terrible either, and can be partially
mitigated by good documentation around EPEL Next workflows.
* modify dist to always be higher than epel8 (.el8.next or similar)
In EPEL Next we could define dist to a string that RPM evaluates higher than
.el8, such as .el8.next. This would allow EPEL and EPEL Next branches to be
in sync and the same commit could be built for both targets. The higher
dist would ensure the upgrade path works.
I think this makes the most sense and will help packages workflows the
best.
kevin