[EPEL-devel] Timeframe for EPEL retirement vs RHEL new package releases

[Daniel P. Berrangé]

A few weeks back there was a little snafu (since resolved) with the
capstone package in EPEL.

This package is being introduced to RHEL 9.2, and thus has been added
to CentOS 9 Stream repos. A bug was filed against capstone in EPEL
to notify that capstone should be retired when RHEL 9.2 is released:

  https://bugzilla.redhat.com/show_bug.cgi?id=2124181

Unfortunately the package was accidentally retired immediately rather
than waiting until 9.2 release. This is an easy mistake for a maintainer
to make when they see a bug whose title is "Remove capstone from epel9",
so I don't want anyone to blame the maintainer for this accident.

Yes the comments make it clear that removal should wait until 9.2
release date, but I can totally understand how actions will be guided
by the initial bug subject if you're just skimming. It was pointed out
that this risk has been identified before:

 
https://lists.fedoraproject.org/archives/list/[e-mail]...

and now we have a real world example of it going wrong exactly as
was predicted.


My bigger concern though is what happens when RHEL-9.2 is actually
released for real. The bug remains open and targets (immediate)
retirement of capstone from EPEL on / near 9.2 release date.


This doesn't feel like it takes into account the real world usage of
enterprise distributions. The kind of people/organizations who deploy
RHEL are rarely going to rush into upgrading their deployment processes
to use 9.2 immediately. They may have all sorts of review and testing
processes to go through, integration of 3rd party apps and services,
validating against hardware, before they consider starting deployment
of RHEL 9.2.

All this time they will continue deploying machines with 9.1, despite
9.2 being available, so won't get access to new 9.2 packages.

If we immediately retire capstone when 9.2 is released, aren't we
going to break any ability to keep deploying capstone from EPEL on
existing/new 9.1 installs ?

There is also the case of the RHEL rebuilds whose users consume EPEL
packages. Depending how quick they are, the rebuild distros might not
have their 9.2 rebuild ready for some days/weeks/months after RHEL-9.2
is first available. My projects' upstream CI is all based on AlmaLinux
and I don't want to see it broken again by premature capstone retirement
from EPEL.

Unless I'm mistaken in some way, it feels like we should *NOT* sync
the removal of packages from EPEL with their release in RHEL 9.2. It
needs to be synced with user deployment of 9.2, which might be somewhat
later.



The package added to RHEL should (must) have a newer NEVR than the
existing package in EPEL, so even if we leave it in EPEL, it will
be ignored if the newer version is present in RHEL repos.

The main important thing I see is that the EPEL branch in dist-git
must be made read-only and/or prevented from submitting new builds,
once the package has been built in CentOS Stream. ie to ensure the
EPEL NEVR doesn't creep back above the pending RHEL package's NEVR.


If that's done it should be fine to leave it in EPEL for a prolonged
period after 9.2 is released, to allow sufficient time for users to
actually switch from deploying 9.1 over to 9.2.

I guess someone might say that EPEL only targets the very latest
y-stream of RHEL, so continuing to use 9.1 after 9.2 is released
is unsupported ?  Even if that is technically the case, I think
in practice users won't take that into account, and thus expect
it to keep working and generally that should be fine. Only if a
EPEL package is rebuilt such that it depends on a newly added
API/ABI is that a problem.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|