On Fri, Sep 24, 2021 at 4:09 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Fri, Sep 24, 2021 at 4:03 PM Josh Boyer <jwboyer(a)redhat.com> wrote:
>
> On Fri, Sep 24, 2021 at 4:02 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
> >
> > On Fri, Sep 24, 2021 at 3:59 PM Josh Boyer <jwboyer(a)redhat.com> wrote:
> > >
> > > On Fri, Sep 24, 2021 at 3:46 PM Ken Dreyer <ktdreyer(a)ktdreyer.com>
wrote:
> > > >
> > > > Hi folks,
> > > >
> > > > The RHEL 9 composes do not have libev-devel and libuv-devel, so we
> > > > cannot build python-gevent on EPEL 9 easily.
> > >
> > >
https://odcs.stream.centos.org/production/CentOS-Stream-9-20210924.0/comp...
> > >
> > > You could request libev-devel in the composes. I remain confused why
> > > it has to be in the compose though, because libev and it's devel
> > > package are accessible in the CentOS Stream 9 buildroots today.
> > >
> >
> > We can't use them in EPEL if they're not in CRB.
>
> Yes, that's what everyone keeps telling me. I don't understand why.
>
Well, because outside of RHEL, everyone wants remote and local builds
to have access to the same resources and not crush the servers. Since
buildroot stuff isn't going out on the mirror network (otherwise, why
would it be separate from CRB?), it's obvious we shouldn't rely on it
for packages that people should expect to be able to build and rebuild
for RHEL.
So you have access to what you want, you have a way to pull it down
and get it locally, but you can't depend on it because... you're
worried a multi-billion dollar company can't pay it's server and CDN
bills?
As to why it's separate from CRB, that's because CRB is a reflection
of what is provided as part of the product. It's that simple.
And again, by Red Hat's own sword (policy), RHEL doesn't want
to ship
everything needed to build stuff, so if EPEL is intended to provide
the requisite community guarantees (reproducibly buildable), we have
to work with what RHEL gives us.
I think that is also EPEL falling on EPEL's own sword a bit. I think
it fails to recognize that building and distributing software can be
separate things. I can see the need for a developer community to be
able to build, update, and rebuild software it distributes. Access to
the buildroots facilitates this. We could even point mock configs at
it, or propose a buildroot repo for it if people are really worried
about "servers".
However, in the context of something like python-gevent, an EPEL *end
user* isn't going to want libuv-devel or libev-devel to be installed
on their system at runtime. They have no need for it to be available
in a compose. They only need python-gevent and the requisite runtime
libraries, which are already provided. I think separating the
personas and thinking about the requirements for each might be worth
doing.
I understand this is a different approach and something that looks
different from the past. It's been 2+ years since the OS EPEL8 is
based on has shipped and it is taking a different approach than
previous releases. Every indication we have shows the next major
version will continue this. I'm worried that sticking with past
policies precludes EPEL from making progress on a project that we all
want to see succeed.
josh