On Fri, Jun 25, 2021 at 2:02 PM Josh Boyer <jwbo...@redhat.com> wrote:
> On Thu, Jun 24, 2021 at 4:32 PM Troy Dawson <tdaw...@redhat.com> wrote: > > > > During our last round of proposals for solutions to missing devel > packages, it was noted that EPEL and CentOS has very different > documentation for requesting a package be put into RHEL 8.[1][2] > > > > I am betting that CentOS's documentation is correct. It was written > after ours. > > > > When I was talking to the Red Hat people who know, it was noted that Red > Hat has much better communication with the Fedora and CentOS communities > than the EPEL community.[3] They wanted to start fixing that communication > gap, and figured this would be a good way to start. So I'm asking Josh > Boyer to answer this question on behalf of Red Hat. > > Thanks, Troy! > > > How would Red Hat like us, EPEL maintainers and developers, to request > missing devel packages? (devel packages that are built at the same time as > a released library in RHEL8, but not released in RHEL8. Such as lmdb-devel) > > The process as documented on the CentOS wiki page is the best route. > Filing a bug against the package in the Red Hat Enterprise Linux > product family with the CentOS Stream version set will ensure that > both the team maintaining the package in RHEL and some from the CentOS > Stream team are looped in. Getting the request in front of the owning > RHEL team is key, as they will need to evaluate the request and > consider the implications of providing the devel package. > > I would like to make sure and clarify that this is the best approach > for devel packages from SRPMs that are already part of RHEL. > Completely new package requests for things that are not in RHEL at all > are RFEs that should likely come through a case filed in the Customer > Portal for those that have a valid subscription. > > > If we follow Red Hat's procedure, what are the odds that the package > will make it into RHEL 8 CRB? > > This one is harder to answer in a general sense. I don't want to be > misleading, so I won't give odds because it will vary depending on the > package. I'll certainly say the odds are better if the requests are > made than if they aren't :) We have grown the CRB content set by over > 100 packages since the initial RHEL 8.0 release, and continue to add > packages even today. I'd like to also describe some of the > considerations at play as we work on this. > > Essentially, the team that owns the package will evaluate the request > to ensure it's consistent with the manner in which the package is > intended to be used as part of RHEL. Often enabling other software to > build against a RHEL package, particularly for things like EPEL > enablement, is a perfectly valid use case. Once a valid use case has > been established the team will ensure they can meet any obligations > required by adding it as part of the RHEL product and sign off. After > the team has agreed, the package will first appear in CentOS Stream > PowerTools (or occasionally AppStream), and then in a future RHEL > minor release. > > At times, we have included a library or package as an internal > implementation detail and do not encourage wider use of that package > for other software. This is a relatively rare case. I can only think > of one stand-out package that comes to mind thus far. If it does > happen the team may decide not to provide the devel package. Filing > the request is often the best way to begin that dialog. This helps us > understand how a package is being used and take that into > consideration for future RHEL releases, and also allows discussion and > suggestions for alternative packages that may be more suitable in the > long term. > > I'm sure there are many that would simply like all subpackages of all > SRPMs to be shipped, however that is not the approach RHEL is taking > from a product perspective. Blanket requests for everything are not > likely to go far. It's simply not actionable at the same level as > targeted requests. > > As an aside, I am particularly encouraged to see EPEL-Next come to > fruition and combined with CentOS Stream and the broader set of > packages available in that project buildroot I think there is a lot of > potential to grow the overall ecosystem. I believe EPEL has discussed > this recently with some hesitation, but I would encourage you to > consider if and how EPEL-Next and CentOS Stream might be leveraged to > help EPEL proper as well. From what I've seen, this community is > amazing and I think there are opportunities there. > > Thanks again Troy, for giving me the opportunity to interact with the > EPEL community. This is quite overdue. > > josh > > Thank you Josh for your reply. This will help us as we move forward. We have updated out EPEL FAQ concerning this. Troy [1] - https://fedoraproject.org/wiki/EPEL/FAQ#RHEL_8.2B_has_binaries_in_the_release.2C_but_is_missing_some_corresponding_-devel_package._How_do_I_build_a_package_that_needs_that_missing_-devel_package.3F
_______________________________________________ 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
