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).
--
Sent from my phone, apologies for any brevity as well as autocorrect
Bryan J Smith - http://linkedin.com/in/bjsmith
Sent from my phone, apologies for any brevity as well as autocorrect
Bryan J Smith - http://linkedin.com/in/bjsmith
On Tue, Mar 28, 2023, 11:14 Carl George <carl@xxxxxxxxxx> wrote:
I'm also late to the party with this feedback, but just in case it's
not too late to include, can we include something about not updating
the package further? Beyond just "you do not need to take any
action", we should advise against making any changes at that point, as
often the RHEL package will be exactly one release higher than the
current EPEL package, and updating the EPEL package further (either
release or version) will screw up the upgrade path.
On Mon, Mar 27, 2023 at 7:22 PM Troy Dawson <tdawson@xxxxxxxxxx> wrote:
>
> On Sat, Mar 25, 2023 at 12:51 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
>>
>> On 20. 03. 23 12:20, Neal Gompa wrote:
>> >> I could think of other reasons as well. E.g. it's not important for customers
>> >> but it's important for Red Hat. Or maybe it is a not-so-important dependency of
>> >> something else.
>> >>
>> > Does Red Hat have any other motivation with RHEL other than a customer
>> > needing the functionality? Those other reasons are generally driven by
>> > someone needing it.
>>
>> See e.g. https://bugzilla.redhat.com/2175213
>
>
> I see your point. It sometimes also happens when the EPEL package is a dependency of the important package, the customers aren't actually asking for the EPEL package.
> It looks like this change still hasn't been merged in so I'll see if I can get a change in. How about this?
>
> Subject:
> Notice: <package> will be automatically retired from EPEL <major> when RHEL <major>.<minor> is released
>
> Comment:
>
> This issue is purely informational, you do not need to take any action. Thank you for your work maintaining <package> in EPEL <major>. Red Hat considers this package important enough to promote it to official RHEL. It will be part of RHEL <major>.<minor>. When that is released, EPEL automation will remove <package> from EPEL <major> and close this bug.
>
> _______________________________________________
> 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
--
Carl George
_______________________________________________
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
_______________________________________________ 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
