On Fri, 3 Mar 2023 at 06:42, Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
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 has been a problem with EPEL since its formation in EL4/EL5 timeframe. The primary reason EPEL was given resources from Fedora was that infrastructure and release engineering needed certain packages to run on EL4/EL5 which weren't in RHEL. The primary reason most Fedora packagers put packages into EPEL is as long as whatever goes on in RHEL doesn't affect what they are doing day to day.
In EL5, EL6 there was not a lot of rebasing and updates between y-streams but packages would move from EPEL in RHEL which would require cleanup after the sub-release was out. In EL7 we started to see more rebasing of the graphics stack which would cause different sorts of breaking in some applications and rebuilds and splits. In EL8, the trend has accelerated and the dot releases may see things move in and out of RHEL breaking EPEL packages. However, consumers of EPEL move at different speeds so we have some who stay on the latest, and others who are way behind. These breaks in 7 and 8 had it that we tried to archive off things in two different ways. After a y-stream was released, EPEL-X.Y would be snapshotted to /pub/archive for people who needed older things without updates. And for people to try and get ahead of the curve we tried first EPEL-playground and then EPEL-next to allow things to build against a newer grouping.
Trying to do more for Enterprise consumers has run into several major impediments.
1. Fedora infrastructure (builders, disk space, volunteer mirrors, engineers) has been at or over capacity in trying to deal with the current Fedora package set and regular releases. Most of the changes to enhance EPEL to deal with slower cadences requires more dedicated time, disk space, mirrors and engineer time than has been possible.
2. Fedora packagers are at capacity for dealing with EPEL packaging. They are mostly aimed at trying to keep up with the firehose of a regular Fedora release every 6 months. Trying to keep up with slower releases usually causes dropped packages in both EPEL and Fedora. Trying to deal with even more 'branches' than the main one for a release has been problematic.
3. Package dependency lists have grown exponentially which require more disk space and volunteer time.
* an x-stream is the major release of an EL operating system. EL9 is the X stream.
* a y-stream is the dot release which comes out every ~6 months. 9.1 is the current Y stream.
I guess there may be a 'z' stream for when some older release gets updates over time (The regular mass updates to EL7.9 would be a z-stream)
Solutions to the problems have to take all three of those impediments into consideration to be done. My attempt with EPEL-playground in 8 broke down on (2) Fedora packagers not having the capacity to deal with different workflows and (1) infrastructure limits. EPEL-Next seems to be running into 1, 2 and 3.
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren_______________________________________________ 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
