We currently have a FAQ entry documenting what happened if there are subpackages that are built in EL but not shipped to the repos, for which we can ship the missing subpackages in EPEL from -epel packages that are exempted from review. And this is a short term solution as we should request they are shipped in CRB.
-epel
Another case (that is not documented, but there's a convention e.g. https://src.fedoraproject.org/rpms/systemd-extras/tree/epel8) is to ship subpackages that are disabled upstream in -extras. These packages need to be reviewed.
There turns out to be a third case, how to ship subpackages that are disabled using conditionals, e.g. https://gitlab.com/redhat/centos-stream/rpms/iptables/-/blob/c9s/iptables.spec#L11 / https://src.fedoraproject.org/rpms/iptables-epel/tree/epel9 .
Are these changes trivial enough that the source package should be named -epel, or is this an -extras? Is review required?
-extras
Once we have a policy for this, we should probably also write a standalone doc for these three cases rather than having a single FAQ entry.
Metadata Update from @salimma: - Issue tagged with: epel-packagers-sig, meeting
Also to be considered: - Carl brought up that maybe review exceptions are not a good idea anyway. Given how much the spec needs to be changed if we rename a package (any references to %{name} is wrong), and that there are two possible EPEL package naming scheme, maybe requesting review (with the steering committee resolving disagreements) is better - for cases that we likely need to maintain long term (e.g. systemd-extras) should we file MRs upstream adding conditionals so we can reduce the maintenance burden? Is upstream maintainer likely to accept these?
The original intention of the review exception was to make it easy to provide subpackages that were either 1) already built as part of the RHEL spec file but not shipped in RHEL or 2) already part of a reviewed package in Fedora but were not included in the equivalent RHEL spec file. I think the scenario of a conditionally disabled subpackage is close enough to the former to be considered the same thing. That said, in hindsight it seems the implementation in all these cases can be complicated enough to still warrant a package review. Even though I was the one who originally proposed that exception, I'm not opposed to repealing it.
The -epel suffix convention came later, and I think it was mostly used for the unshipped scenario. I would be fine standardizing all scenarios to use this convention. I'm only aware of systemd-extras that doesn't follow that convention. I'm not sure if it's worth the effort to rename it to systemd-epel, or just recommend the -epel suffix for packages going forward.
Having the subpackages in question as part of the RHEL spec file but enabled/disabled by conditionals seems appropriate to me. I doubt all RHEL maintainers will agree to merge such changes, but it's always worth asking.
I've been thinking of this the past week and these are my thoughts.
At the last EPEL Steering Committee meeting this was discussed. The above comment was approved. It was decided that this would be a "MUST" policy going forward. All packages that have already been created with -epel or -extra can remain as they are, or be renamed to match the policy, at the maintainers discretion.
This policy will be written up as a pull request for the official EPEL documentation. The exact wording can be decided in that pull request.
Metadata Update from @tdawson: - Issue untagged with: meeting
The policy for missing sub-packages has been written up and if found here. https://docs.fedoraproject.org/en-US/epel/epel-policy-missing-sub-packages/
Metadata Update from @tdawson: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.