As a lurker of no note (feel free to ignore this rest of this post) I have resisted commenting since the thread started last fall. And I'm sure anything I post might come off as 'from the peanut gallery,' as it probably should. I'm going 'off-topic,' but I feel it's related. And I don't envy the EPEL maintainers, and their pains are something that most others will never understand well.
But given the EPEL2RHEL aspect, I figured this was as good of a thread to tangent from.
With the success of and major account buy-in of CentOS Stream, despite the negative press due to the messaging problems (not unlike Fedora 20 years ago), I'm really at the point I think Red Hat needs to step in, strategically, and address this in a greater way, by support EPEL maintainers more directly... possibly via Stream steering?
Not-so-differently than how Fedora Extras and Fedora Core were addressed within 5 years... but, I'm probably over simplifying things.
Because even today, like I started a dozen years ago, as a RHEL consumer, even for development systems**, I've pretty much continued to only use EPEL on RHEL via 'includepkgs=' in YUM, now DNF, previously updated by Puppet, now Ansible (and definitely after seeing Ansible itself upgraded to a newer version in EPEL years ago). And so with every new RHEL Update, I ensure any changes in those whitelists, including via Stream and Next, along with the Update Betas.
Maybe I'm ignorant, and some of this is already in progress or at least under consideration, but I think it would address a lot of things if CentOS Stream and EPEL steering was more integrated, if not during the Stream/RHEL9 lifecycle, but for 10. I haven't been able to get away from whitelists (includepkgs=) completely, not even with Modular (although that has helped immensely, like with Ansible itself too).
E.g., I for one, just have to 'shake my head' when I see all the various CentOS Stream 'repositories,' and have to ask myself... what if that effort by Red Hat engineers was put into assisting EPEL as well, even finally integrating them, via Modularity?
Just an observation, from the 'peanut gallery,' and I could be quite ignorant. That and I know nothing changes overnight, but the segmentation with EPEL doesn't have to be like CentOS was before Stream in 2019.
- bjs
**P.S. even though I still advocate everyone get a free RHEL Developer Entitlement, and argued for it to become free even before 2014, when I was on the inside of Red Hat (and love the recent move to 16 entitlements), so professionals and enthusiasts alike can run actual RHEL... I'm still loving the fact that Stream is now public, and we have standardized on Stream for container development.
E.g., although ultimately we do deliver for RHEL, we don't let UBI limit our considerations, and it becomes more of a 'develop what's possible' and then evaluate whether the deliverable can run on the UBI (possibly with library alternatives), or if a full entitlement is required (we just need stuff not in the UBI).