On Thu, Jan 27, 2022 at 09:35:27PM -0800, Michel Alexandre Salim wrote: > Hi all, > > I just filed https://pagure.io/epel/issue/152 to ask if we should > revisit the policy for https://docs.fedoraproject.org/en-US/epel/epel-packaging/#limited_arch_packages > > This policy seems very similar to the policy we agreed on in > https://pagure.io/epel/issue/134 (but haven't documented yet) which > deals with missing subpackages of two kinds: > - built but not shipped > - disabled from building > > except this time it's architectures that are either excluded from build, > or excluded from being shipped. > > Neal is trying to package LibRaw, which is built on all arches but has > been shipped only for x86_64: > > review request: https://bugzilla.redhat.com/show_bug.cgi?id=2047560 > rejected RHEL 8 request to ship LibRaw: https://bugzilla.redhat.com/show_bug.cgi?id=1956029 > rejected RHEL 9 request: https://bugzilla.redhat.com/show_bug.cgi?id=2012272 The limited arch policy we had for epel7 had a number of problems. At first we just said 'rebuild the exact rhel version' and then we switched to 'add a 0 to release so the rhel package always gets installed in favor of it'. We also didn't have any kind of record keeping or process, so we have no idea how many of these there were, and they continued to just surprise people over and over again. ;( > Details in the ticket, but TL;DR > - why is EPEL 8 excluded from the limited arch policy, and would the > recommendation in issue 134 to use a different srpm name resolve the > issues there? I think we didn't allow it for epel8 for the above reasons. A different name might make it easier for the packager, but not for tracking or visibility. > - assuming we still disallow EPEL 8, is EPEL 9 fine? I'd say no, until we approve a new policy. > - can we merge that policy with the policy we have to write for issue > 134 anyway? Perhaps. The difference here is that people will see a epel package 'newer' than the rhel one and get it installed (in cases where rhel does ship it). Thats what the 0 leading release was supposed to help with, but it adds a bunch of complexity. > - in case of limited arch packages, should the new srpm be `-epel` or > `-extras`? It's very lightly edited from the original (see Neal's > review request) as we don't even have to disable certain subpackages: > - rename %name > - rename back all the generated packages > - add changelog > but on the other hand, in this case it's very long lived as it's not > just a matter of "we can persuade RH to ship it in CRB, it's not > supported anyway" I personally don't much care, but we should pick one. ;) > - should we come up with review guidelines for this? fedora-review seems > overkill as in most cases we don't want to diverge from the CentOS > Stream upstream anyway. At the very least we should make a requirement to add a provides or something so we can find these and see them. kevin
Attachment:
signature.asc
Description: PGP 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
