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/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx/thread/LUWUIN5BRPJZGVB5PIH625PFV6IBD6YO/ 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 :| _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
