RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2017116 - Add libev-devel to CRB
Summary: Add libev-devel to CRB
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: libev
Version: CentOS Stream
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Kamil Dudka
QA Contact: Frantisek Sumsal
URL:
Whiteboard:
: 2030089 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-10-25 16:04 UTC by Peter Georg
Modified: 2021-12-08 16:17 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-10-26 13:00:34 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-100719 0 None None None 2021-10-26 07:04:13 UTC

Description Peter Georg 2021-10-25 16:04:37 UTC 
Description of problem:
In order to build i3 and i3lock for EPEL, we need libev-devel available at build-time in CRB. Please ship libev-devel for this.
Comment 1 Kamil Dudka 2021-10-26 07:01:16 UTC 
(In reply to Peter Georg from comment #0)
> Description of problem:
> In order to build i3 and i3lock for EPEL, we need libev-devel available at build-time in CRB.

I do not think we have business justification for supporting i3* or rxvt-unicode in EPEL-9.  libev was pulled in because it was needed by nghttp2.  Exposing libev-{devel,source} in CRB would increase the maintenance burden on Red Hat's side.  If you are a customer of Red Hat, please contact product support with your request.

> Please ship quota-devel for this.

It is unclear to me how quota-devel is related.
Comment 2 Peter Georg 2021-10-26 10:35:15 UTC 
(In reply to Kamil Dudka from comment #1)
> (In reply to Peter Georg from comment #0)
> > Description of problem:
> > In order to build i3 and i3lock for EPEL, we need libev-devel available at build-time in CRB.
> 
> I do not think we have business justification for supporting i3* or
> rxvt-unicode in EPEL-9.  libev was pulled in because it was needed by
> nghttp2.  Exposing libev-{devel,source} in CRB would increase the
> maintenance burden on Red Hat's side.

This expected answer sounds reasonable and I can not really argue against. It once again shows the issue of shifting and increasing maintenance burden for others.
The problem here is that libev being pulled in increases the maintenance burden for anyone who wants to provide the missing subpackages in EPEL 9.
It would not be an issue at all if libev was not included in the first place. In this case I'd happily volunteer to provide libev (including its subpackages) in EPEL 9.

But this general problem with not shipped subpackages is not new. It exists since EL 8 and possible generic solutions have been discussed.

> If you are a customer of Red Hat,
> please contact product support with your request.
CentOS Stream user, no customer.

> > Please ship quota-devel for this.
> 
> It is unclear to me how quota-devel is related.

Sorry, this was a simple copy&paste error of lazy me. It is not related at all.
Comment 3 Josh Boyer 2021-10-26 10:57:09 UTC 
(In reply to Peter Georg from comment #2)
> (In reply to Kamil Dudka from comment #1)
> > (In reply to Peter Georg from comment #0)
> > > Description of problem:
> > > In order to build i3 and i3lock for EPEL, we need libev-devel available at build-time in CRB.
> > 
> > I do not think we have business justification for supporting i3* or
> > rxvt-unicode in EPEL-9.  libev was pulled in because it was needed by
> > nghttp2.  Exposing libev-{devel,source} in CRB would increase the
> > maintenance burden on Red Hat's side.
> 
> This expected answer sounds reasonable and I can not really argue against.
> It once again shows the issue of shifting and increasing maintenance burden
> for others.
> The problem here is that libev being pulled in increases the maintenance
> burden for anyone who wants to provide the missing subpackages in EPEL 9.
> It would not be an issue at all if libev was not included in the first
> place. In this case I'd happily volunteer to provide libev (including its
> subpackages) in EPEL 9.
> 
> But this general problem with not shipped subpackages is not new. It exists
> since EL 8 and possible generic solutions have been discussed.
> 
> > If you are a customer of Red Hat,
> > please contact product support with your request.
> CentOS Stream user, no customer.

The libev-devel package is available in the CentOS Stream buildroots.  I'm aware that EPEL doesn't build against those, but EPEL-Next does and you may find it perfectly suitable to build there and use that given that you are a CentOS Stream user.
Comment 4 Peter Georg 2021-10-26 12:00:47 UTC 
(In reply to Josh Boyer from comment #3)
> (In reply to Peter Georg from comment #2)
> > (In reply to Kamil Dudka from comment #1)
> > 
> > > If you are a customer of Red Hat,
> > > please contact product support with your request.
> > CentOS Stream user, no customer.
> 
> The libev-devel package is available in the CentOS Stream buildroots.  I'm
> aware that EPEL doesn't build against those, but EPEL-Next does and you may
> find it perfectly suitable to build there and use that given that you are a
> CentOS Stream user.

There has been a discussion about using the CentOS Stream buildroot on epel-devel mailing list recently.
See especially https://www.mail-archive.com/epel-devel@lists.fedoraproject.org/msg09077.html
My understanding was that epel-next 9 will use CentOS Stream buildroot at the beginning to not delay the process, but switch later.
I.e. your suggestion is a work-around for now, but won't work for EPEL-next 9 at a later point in time and obviously never work for EPEL 9.

Am I misunderstanding something?
Comment 5 Josh Boyer 2021-10-26 12:04:58 UTC 
(In reply to Peter Georg from comment #4)
> (In reply to Josh Boyer from comment #3)
> > (In reply to Peter Georg from comment #2)
> > > (In reply to Kamil Dudka from comment #1)
> > > 
> > > > If you are a customer of Red Hat,
> > > > please contact product support with your request.
> > > CentOS Stream user, no customer.
> > 
> > The libev-devel package is available in the CentOS Stream buildroots.  I'm
> > aware that EPEL doesn't build against those, but EPEL-Next does and you may
> > find it perfectly suitable to build there and use that given that you are a
> > CentOS Stream user.
> 
> There has been a discussion about using the CentOS Stream buildroot on
> epel-devel mailing list recently.
> See especially
> https://www.mail-archive.com/epel-devel@lists.fedoraproject.org/msg09077.html
> My understanding was that epel-next 9 will use CentOS Stream buildroot at
> the beginning to not delay the process, but switch later.
> I.e. your suggestion is a work-around for now, but won't work for EPEL-next
> 9 at a later point in time and obviously never work for EPEL 9.
> 
> Am I misunderstanding something?

I don't know why EPEL-Next would ever switch away from using the CentOS Stream 9 buildroot.  It kind of defeats the purpose of the "next" aspect.
Comment 6 Peter Georg 2021-10-26 12:38:42 UTC 
(In reply to Josh Boyer from comment #5)
> (In reply to Peter Georg from comment #4)
> > (In reply to Josh Boyer from comment #3)
> > > (In reply to Peter Georg from comment #2)
> > > > (In reply to Kamil Dudka from comment #1)
> > > > 
> > > > > If you are a customer of Red Hat,
> > > > > please contact product support with your request.
> > > > CentOS Stream user, no customer.
> > > 
> > > The libev-devel package is available in the CentOS Stream buildroots.  I'm
> > > aware that EPEL doesn't build against those, but EPEL-Next does and you may
> > > find it perfectly suitable to build there and use that given that you are a
> > > CentOS Stream user.
> > 
> > There has been a discussion about using the CentOS Stream buildroot on
> > epel-devel mailing list recently.
> > See especially
> > https://www.mail-archive.com/epel-devel@lists.fedoraproject.org/msg09077.html
> > My understanding was that epel-next 9 will use CentOS Stream buildroot at
> > the beginning to not delay the process, but switch later.
> > I.e. your suggestion is a work-around for now, but won't work for EPEL-next
> > 9 at a later point in time and obviously never work for EPEL 9.
> > 
> > Am I misunderstanding something?
> 
> I don't know why EPEL-Next would ever switch away from using the CentOS
> Stream 9 buildroot.  It kind of defeats the purpose of the "next" aspect.

It will still allow to build content for CentOS Stream 9 by using the released composes instead of the buildroot.
Building EPEL packages for CentOS Stream is the main aspect of "next", isn't it?

Anyway this is about EPEL politics/decisions and hence off-topic here.
Comment 7 Kamil Dudka 2021-10-26 13:00:34 UTC 
Please feel free to discuss a more generic solution here or elsewhere.  Nevertheless, including the libev-{devel,source} subpackages into CRB does not seem to be a reasonable action from package maintainer's perspective.
Comment 8 Leon Fauster 2021-12-08 15:58:12 UTC 
Its starts obviously now. CS9 are getting attention and therefore the cases for such request are appearing. Just for the statistics #2030089
Comment 9 Kamil Dudka 2021-12-08 16:17:42 UTC 
*** Bug 2030089 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.