On Thu, Jun 24, 2021 at 4:32 PM Troy Dawson <tdawson@xxxxxxxxxx> 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 > > Thanks > Troy Dawson > > [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 > [2] - https://wiki.centos.org/FAQ/CentOS8/UnshippedPackages > [3] - Yes, I write my emails here from my redhat email address, but I do not represent Red Hat in my EPEL capacities. _______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
