On Fri, Sep 24, 2021 at 4:09 PM Neal Gompa <ngomp...@gmail.com> wrote: > > On Fri, Sep 24, 2021 at 4:03 PM Josh Boyer <jwbo...@redhat.com> wrote: > > > > On Fri, Sep 24, 2021 at 4:02 PM Neal Gompa <ngomp...@gmail.com> wrote: > > > > > > On Fri, Sep 24, 2021 at 3:59 PM Josh Boyer <jwbo...@redhat.com> wrote: > > > > > > > > On Fri, Sep 24, 2021 at 3:46 PM Ken Dreyer <ktdre...@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/compose/CRB/x86_64/os/Packages/libuv-devel-1.42.0-1.el9.x86_64.rpm > > > > > > > > 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 _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
