On Fri, Mar 3, 2023 at 9:16 AM Stephen Smoogen <ssmoogen(a)redhat.com> wrote:
On Fri, 3 Mar 2023 at 06:42, Daniel P. Berrangé <berrange(a)redhat.com> 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@lists.fedoraproj...
>
> 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)
My understanding is that Y-stream refers to the upcoming minor version
(a.k.a. CentOS Stream), not the current one. Once a minor version is
publicly released in RHEL, it's referred to as a Z-stream. The
current RHEL minor versions are the latest Z-streams. EUS releases
are the previous Z-streams that are selected for additional security
fixes. So when a RHEL maintainer refers to Z-stream work, they're
talking about public RHEL minor versions that are still maintained.
When they refer to Y-stream work, they're talking about work in CentOS
Stream in preparation for the next RHEL minor version.
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(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)lists.fedoraproject.org
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@lists.fedoraproj...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
Carl George