On 1/14/22 05:02, Josh Boyer wrote:
On Fri, Jan 14, 2022 at 5:31 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:On 14. 01. 22 5:11, Orion Poplawski wrote:While working on EPEL9, it seems that even more packages are missing from RHEL9 than were in RHEL8. The latest I found was cppunit, which appears to be completely missing from the CS9 repos despite having been built (See https://kojihub.stream.centos.org/koji/packageinfo?packageID=2414) and presumably in the CS9/RHEL9 buildroot. So I scraped some screens from pkgs.org: Stream 9: CentOS AppStream Official x86_64 8882 CentOS BaseOS Official x86_64 2357 CentOS CRB Official x86_64 1856 Stream 8: CentOS AppStream Official x86_64 15008 CentOS BaseOS Official x86_64 6721 CentOS PowerTools Official x86_64 3771 That's a pretty big difference. Now, I don't know how many were dropped completely and how many are of the "buildroot only" variety. But I suspect there is a fair amount of the latter and so a lot of make-work ahead of us for EPEL9.A fairly accurate list of packages removed in RHEL 9 can be found in our RHEL 9 Adoption documentation: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9-beta/html-single/considerations_in_adopting_rhel_9/index#removed-packages_assembly_changes-to-packages
Thanks for that.
Packaging for EPEL9 is starting to feel more and more like cleaning the Augean stables with RedHat piling up more manure.If there is any Python stuff that's in Buildroot only, let me know and I'll do my best to persuade the maintainers to move it to CRB (but my powers are limited).I will politely point out two things. 1) The entirety of the RHEL buildroot is available in the CentOS Stream koji buildroots. I know the EPEL stewards have qualms about using it, but they are there and the technical hurdles to consume them are not large.
Well, we are making use of it via epel-next. But it's the "Stream" buildroot. Once that diverges from the current released RHEL there could be issues with trying to do updated builds for the current release of RHEL.
2) Moving content to CRB in RHEL is not a silver bullet solution in many scenarios. If it's strictly for build dependencies, CRB works well. If an EPEL package has a runtime requires on CRB content, that is less desirable. RHEL CodeReady Linux Builder (CRB) content is unsupported, not enabled by default, and not intended to be used at runtime in production. EPEL itself is clearly in the same unsupported category, but requiring another unsupported repo at runtime may lead to unintentional surprises for many users. josh
I don't buy any of these arguments, and it doesn't really address the situation of "missing -devel" packages. E.g. utf8proc - it's in "AppStream" - so it's presumably "supported" and "intended to be used at runtime in production". But without the -devel package available we can't build anything in EPEL that uses it. So we have to go through contortions to make sure we build the proper version of utf8proc-devel and keep it in sync with RHEL.
Is the trade off of perhaps a few less RHEL support requests about a few packages that are clearly important enough to be included directly in RHEL really worth the ill-will being generated in the volunteers that help support the ecosystem around RHEL?
Perhaps it's unreasonable for me to be as upset about this as I am, but largely it's because I just can't understand the motivation behind it and it's a deliberate action that directly makes my *volunteer* work harder. I have put in thousands of hours of work on Fedora/EPEL over 16+ years - and generally it has just gotten better. Better tools, better infrastructure, etc. This is the first time I can remember having something change that makes the work harder - so maybe it's just the shock of that. Feels like a betrayal of those 16 years of working together towards what seemed like a common goal.
Oh, and for cppunit just putting it in CRB should be just fine as it generally does not produce runtime deps.
-- Orion Poplawski he/him/his - surely the least important thing about me Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion@xxxxxxxx Boulder, CO 80301 https://www.nwra.com/
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 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
