12:20 p.m.
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
On Tue, Mar 28, 2023, 11:14 Carl George <carl(a)redhat.com> 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(a)redhat.com> wrote:
>
> On Sat, Mar 25, 2023 at 12:51 PM Miro Hrončok <mhroncok(a)redhat.com>
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(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
_______________________________________________
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