Bug 2017116

(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.

(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.

(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.

(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?

(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.

(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.

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.

Its starts obviously now. CS9 are getting attention and therefore the cases for such request are appearing. Just for the statistics #2030089

*** Bug 2030089 has been marked as a duplicate of this bug. ***