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_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
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