https://bugzilla.redhat.com/show_bug.cgi?id=2251952 Carl George 🤠 <carl@xxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED Assignee|nobody@xxxxxxxxxxxxxxxxx |carl@xxxxxxxxxx --- Comment #10 from Carl George 🤠 <carl@xxxxxxxxxx> --- > I think instead of creating separate package for just epel, I think request should be made to move perl-lasso from buildroot into CRB repository, at least for RHEL9. I would consider that cleaner way than creating epel-only package. I agree, that would indeed be a more optimal solution long term. Encouraging the lasso-epel route was based solely on this being declined in bug 2041941. If you are able to influence that and get the perl-lasso subpackage shipped in CRB, I would certainly prefer that path. In the mean time, we can proceed with lasso-epel, and just retire it when/if the CRB request gets completed. > It would take a lot of time, but I think is more preferred solution than continuing this review. Not too much time really. Once the RHEL maintainer for lasso agrees to shipping perl-lasso in CRB, they can increment the release of the package with no other changes and complete a CentOS Stream build. That build could be shipped in the next CentOS Stream compose, which usually happens weekly. That would get community members a public RPM artifact that they could start to use. EPEL maintainers can leverage it via EPEL Next. It would take a few more months to show up in RHEL 9.4 CRB to be used by the main EPEL repo. > A package, which conflicts with RHEL packages, cannot be included in EPEL. That is the purpose of the -epel suffix for this package. It allows the package to exist in Fedora dist-git without runing afoul of the logic that blocks dist-git repo names that match RHEL SRPM names. The built packages would not conflict as long as lasso-epel doesn't ship any subpackages that are shipped in RHEL. EPEL packages are allowed to conflict with packages that are only in the RHEL buildroot and not shipped in the public repos. This is standard practice endorsed by the EPEL Steering Committee. https://docs.fedoraproject.org/en-US/epel/epel-policy-missing-sub-packages/ https://docs.fedoraproject.org/en-US/epel/epel-packaging-examples/ https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy > It would make sense to include only epel7 version of this package, because that won't be exported this way. Xavier only mentioned needing this for EL8 and EL9, so maybe we can just skip epel7, considering how close it is to EOL anyways. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2251952 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202251952%23c10 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-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/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
