epel

#152 Revisiting policy for limited arch packages
Closed: Fixed by tdawson. Opened by salimma.

Closed: Fixed
Reopen Issue

This is related to https://pagure.io/epel/issue/134, and I initially thought we can apply the recommendation of using a -extras package that just ExcludeArch the architectures shipped in RHEL/CentOS Stream, but then it turns out https://docs.fedoraproject.org/en-US/epel/epel-packaging/#limited_arch_packages already exists.

The recommendations seem overly restrictive:
- EPEL 7 is allowed, but EPEL 8 is not
- EPEL 9 is not mentioned at all

What are the issues alluded to here?

Because we have had problems with these packages causing either build, compose, or user problems, we are not allowing this for EPEL8

And is it mostly because the srcname is the same on both sides?

Also, do we still need to keep the revisions with a leading 0? This part is not so bad - just in case RHEL/CentOS Stream ends up reenabling an arch, it will ensure an upgrade path - but we didn't require this for the (upcoming) policy on -extras packages, which could potentially have the same issue.

Seems like we should basically merge the two policies - and have a combined one that describes:
- what to do if some subpackages are built but not shipped
- what to do if some architectures are built but not shipped
- what to do if some subpackages are disabled altogether

(I'm hoping that per the other ticket, the answer in all those cases can be mostly the same -- ship an -extras srpm in dist-git, provide the missing archs/subpackages, make sure there is an upgrade path.

Context: https://bugzilla.redhat.com/show_bug.cgi?id=2047560 for having LibRaw-extras in EPEL -- LibRaw is built for all arches in RHEL 8 but only x86_64 is exported https://bugzilla.redhat.com/show_bug.cgi?id=1956029#c1, and the same for Stream 9 - https://bugzilla.redhat.com/show_bug.cgi?id=2012272

Technically, I think unshipped packages we're supposed to use -epel not -extras, but this is a weird corner case that you could justify either.

Metadata Update from @tdawson:
- Issue tagged with: meeting

After discussion, we have decided to test if we can do arch specific packages in epel8 and epel9.
Our test package is libRaw-epel
https://koji.fedoraproject.org/koji/buildinfo?buildID=1915952
Our test dependency is ImageMagick

Hopefully it works, and if it does, we will update this policy.

We had a successful test.
ImageMagick was able to build on all arches, even though libRaw-epel only had the -devel on the missing arches.
https://koji.fedoraproject.org/koji/buildinfo?buildID=1921399

An updated policy that includes missing arches is being worked on here.
https://pagure.io/epel/pull-request/155

Metadata Update from @tdawson:
- Issue untagged with: meeting

The missing sub-package policy has been published.
https://docs.fedoraproject.org/en-US/epel/epel-policy-missing-sub-packages/

Missing arch packages fall under the definition of "missing built sub-packages" and thus if you have missing packages/sub-packages from certain arches, you can create an -epel package to provide them. The steps for this are in
https://docs.fedoraproject.org/en-US/epel/epel-policy-missing-sub-packages/#missing_built_sub-packages

This has been tested and verified that it works.

Metadata Update from @tdawson:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/epel/steering/issues/152

Please continue any further discussion there.
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.