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_pa...
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
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?
- assuming we still disallow EPEL 8, is EPEL 9 fine?
- can we merge that policy with the policy we have to write for issue
134 anyway?
- 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"
- 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.
Thanks,
--
Michel Alexandre Salim
identities:
https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2