We discussed this at today's EPEL Steering Committee meeting.

• @ngompa agreed to submit a PR to have selinux-policy-epel supplement (inverse of recommends) the selinux-policy package, and use the scratch build artifact from the PR to verify it is installed correctly on upgrades.
• We also noticed this package has only been built for EPEL 10.1, and needs to be built for EPEL 10.0 as well to be available for the RHEL 10 launch. I've submitted a request for that.
• After the first two are implemented, we'll revert epel-release#35 as it doesn't work.

cc: @plautrba

I though Sumplement is already there:

https://src.fedoraproject.org/rpms/selinux-policy-epel/blob/epel10.0/f/selinux-policy-epel.spec#_32

https://src.fedoraproject.org/rpms/selinux-policy-epel/blob/epel10.0/f/selinux-policy-epel.spec#_41

So it is, so we just need to revert the epel-release change.

I though Sumplement is already there:

It's there for the -mls and -targeted subpackages, but not for the main package, which is the one that isn't getting installed.

root@c10:~# dnf -q repoquery --supplements selinux-policy-epel-mls
selinux-policy-mls
root@c10:~# dnf -q repoquery --supplements selinux-policy-epel-targeted
selinux-policy-targeted
root@c10:~# dnf -q repoquery --supplements selinux-policy-epel 
root@c10:~#

This is basically unworkable.

As it turns out, DNF's default exclude_from_weak_autodetect=True setting means that both Recommends: and Supplements: are filtered out for installed packages. Since selinux-policy is generally installed on a system from the beginning, this means that even after installing epel-release, commands like dnf upgrade or dnf reinstall selinux-policy-targeted do not trigger selinux-policy-epel-targeted Supplements for selinux-policy-targeted.

There is basically no scenario where any conditional or weak dependency to pull in selinux-policy-epel works for an existing installed system. To enumerate:

1. Scenario: epel-release has Requires: (selinux-policy-epel if selinux-policy). This results in a non-installable epel-release package since the EPEL repo isn't present yet to resolve the dependency.

2. Scenario: epel-release has Recommends: (selinux-policy-epel if selinux-policy). This results in a permanently ignored dependency. The weak dependency cannot be satisfied at install time, and once installed, DNF will automatically filter it out for all future transaction conditions for evaluation.

3. Scenario: selinux-policy has Requires: (selinux-policy-epel if epel-release). This results in a broken transaction blocking installation since the EPEL repo isn't present yet to resolve the dependency.

4. Scenario: selinux-policy has Recommends: (selinux-policy-epel if epel-release). This results in a permanently ignored dependency. The weak dependency cannot be satisfied at install time, and once installed, DNF will automatically filter it out for all future transaction conditions for evaluation.

5. Scenario: selinux-policy-epel has Supplements: selinux-policy. This only works if a system installs selinux-policy after epel-release is installed. Basically, the EPEL repository must be active on the system prior to installing selinux-policy for this to work. In all other cases, this is a permanently ignored dependency.

In the end, I do not see a reasonable path where selinux-policy-epel will actually function as intended, and I expect that a functionally broken SELinux policy will lead to complaints and issues as software from EPEL covered by selinux-policy-epel will simply never get their policies installed and activated. This will be an immense burden on both EPEL and Red Hat as the bug reports flow in for this setup.

This split should be rolled back.

My proposal is that I'll prepare PRs for affected EPEL packages with

%if 0%{?rhel} >= 10
Requires: (selinux-policy-epel if selinux-policy)
%endif

It kind of follow the idea behind https://fedoraproject.org/wiki/SELinux/IndependentPolicy that packages should be responsible for their own policy.

Is it acceptable for you?

Like this https://src.fedoraproject.org/fork/plautrba/rpms/clamav/c/263e8b7b63ead63dd9a9fcf9ccfabe5d7388dbf8?branch=epel10-selinux-policy-epel

It kind of follow the idea behind https://fedoraproject.org/wiki/SELinux/IndependentPolicy that packages should be responsible for their own policy.

This was never proposed or accepted as policy in Fedora. If you want this to be a thing, it needs to be accepted by FESCo. Not to mention, there are technical limitations in decomposing the SELinux policy, particularly because policy modules have dependencies on the base policy anyway, and if the base policy isn't updated or creates a conflict, then policy modules are broken.

Decomposing the SELinux policy and pushing policy module maintenance away from the SELinux team also requires a ton of documentation that does not currently exist. Documentation on policy features, knobs, tunables, creating policy modules and how the policy module language works, etc. all do not exist today. There is also almost no educational material about how SELinux policies should be made and maintained.

(I personally do have some knowledge of this, but it was based on having to sort of "reverse engineer" it to write policies for snapd and a number of other things.)

You are not saving yourself from effort because fixes still need to go to fedora-selinux/selinux-policy, and then have to come down from there into both selinux-policy and selinux-policy-epel. The latter package must move in lockstep with the former.

This is just massively overcomplicating things for RHEL customers and EL users.

This is reality in Fedora:

$ sudo dnf search selinux | grep -- -selinux.noarch | wc -l
59

It always happen in agreement with the package maintainer, we don't push anybody and we're trying to support maintainers with their problems. The process is documented in mentioned https://fedoraproject.org/wiki/SELinux/IndependentPolicy

selinux-policy-epel is maintained by the same team which maintains selinux-policy and we're work on improving automation about updating selinux-policy-epel.

The goal is that this will not affect EL users other than they'll have 2 more packages installed - selinux-policy-epel{,-targeted} and some SELinux module will be installed with priority 200 instead of 100.

For maintainers, I proposed to provide them PRs with necessary change. I'd build it and push updates as well, but I'm not a supermaintainer.

The motivation behind the split is that there is less SELinux policy modules in standard RHEL policy and so policy rebuild is a little bit faster for those who don't use epel.

Is there a plausible case for people using RHEL without EPEL? I have never met anyone who would do that.

We have this request from Red Hat and I'm not sure I can share more information about background of this decision. The team representatives are holidays these days.

I'm here to resolve this on the technical level.

Is there anything wrong on my proposal to fix it on package level? I can have everything done today, or on Monday in latest.

Like this https://src.fedoraproject.org/fork/plautrba/rpms/clamav/c/263e8b7b63ead63dd9a9fcf9ccfabe5d7388dbf8?branch=epel10-selinux-policy-epel

wrong source branch, real commit is here https://src.fedoraproject.org/fork/plautrba/rpms/clamav/c/eb777cb40f5efef57f68b399a17899e0ddf9efea?branch=epel10-selinux-policy-epel

My proposal is that I'll prepare PRs for affected EPEL packages with

I don't think this proposal is scalable for the number of packages in EPEL. To make things worse, many Fedora maintainers will decline to carry EPEL-specific conditionals in their spec files, so EPEL branches will have to diverge to carry this conditional, preventing them from being fast-forward merged with compatible Fedora commits. In those cases the conditional will also have to be re-added for every new EPEL major version.

It kind of follow the idea behind https://fedoraproject.org/wiki/SELinux/IndependentPolicy that packages should be responsible for their own policy.

As far as I can tell, that is just a wiki page, and isn't official policy. I can't find any reference to it in the packaging guidelines, or any changes that reference it. There previously was a warning about this not being official on the page, but it was removed in 2019 with no explanation.

The goal is that this will not affect EL users other than they'll have 2 more packages installed - selinux-policy-epel{,-targeted} and some SELinux module will be installed with priority 200 instead of 100.

The real problem is getting those package installed. As Neal described, none of the scenarios we can think of will accomplish this.

selinux-policy-epel is maintained by the same team which maintains selinux-policy and we're work on improving automation about updating selinux-policy-epel.

Since your team will be maintaining them anyway, why not just put the selinux-policy-epel{,-mls,-targeted} packages into RHEL itself? They could be shipped in CRB to indicate they are unsupported (ACG level 4). Having the packages in RHEL means that they would be available at the start of the transation when installing epel-release, which would allow us to use conditional dependencies in epel-release like so:

• Requires: (selinux-policy-epel if selinux-policy)
• Requires: (selinux-policy-epel-mls if selinux-policy-mls)
• Requires: (selinux-policy-epel-targeted if selinux-policy-targeted)

As of now:

there are 64 modules in selinux-policy-epel. I went through majority of them and:

• 16 modules are related to 18 packages which need to be updated - I have already patches prepared
• 9 modules are related to dead packages and can be dropped
• 22 modules are related to packages which have not been branched yet, i.e. no epel10 branch
• 17 modules to be reviewed

Since your team will be maintaining them anyway, why not just put the selinux-policy-epel{,-mls,-targeted} packages into RHEL itself? They could be shipped in CRB to indicate they are unsupported (ACG level 4). Having the packages in RHEL means that they would be available at the start of the transation when installing epel-release, which would allow us to use conditional dependencies in epel-release like so:

• Requires: (selinux-policy-epel if selinux-policy)
• Requires: (selinux-policy-epel-mls if selinux-policy-mls)
• Requires: (selinux-policy-epel-targeted if selinux-policy-targeted)

AFAIK CRB is not enabled by default. Users would need to enable CRB first and than install epel-release package. I don't think it would solve the situation.

CRB is already a dependency for EPEL.

Then it should work. Tomorrow I'll prepare a ticket for that and discuss whether it's possible and how do it in a short term.

We discussed this at today's EPEL Steering Committee meeting. One thing that was brought up was that using requires as described above would effectively result in CRB going from a documented dependency of EPEL to a hard dependency enforced by RPM (because epel-release would fail to install if selinux-policy is installed and CRB isn't enabled). The alternative suggested was to use recommends in epel-release instead.

• Recommends: (selinux-policy-epel if selinux-policy)
• Recommends: (selinux-policy-epel-mls if selinux-policy-mls)
• Recommends: (selinux-policy-epel-targeted if selinux-policy-targeted)

This would still be an improvement over the current status, because as long as the documented process is followed (enabling CRB first, then installing epel-release) then the right policy subpackages will get installed.

Here's the RHEL issue for adding the packages to CRB.

https://issues.redhat.com/browse/RHEL-89587

This was implemented in selinux-policy#199 and built as selinux-policy-40.13.31-2.el10. The new build is in the latest compose, however the new subpackages are not yet included. I've submitted pungi-centos#1000 to fix this.

It's worth noting that the package names ended up using "extra" instead of "epel", so after those packages are available in both CentOS and RHEL, we should switch the epel-release recommends from selinux-policy-epel to selinux-policy-extra.

The pungi PR has been merged, and the selinux-policy-extra, selinux-policy-mls-extra, and selinux-policy-targeted-extra subpackages are now present in the CentOS-Stream-10-20250611.0 compose. That compose is also now live on the mirrors, and I can confirm the packages get installed if the corresponding non-extra subpackages are already installed at the time of epel-release installation.

[root@fe97bca7a538 ~]# rpm -qa | grep selinux-policy
selinux-policy-40.13.33-1.el10.noarch
selinux-policy-targeted-40.13.33-1.el10.noarch
selinux-policy-mls-40.13.33-1.el10.noarch
[root@fe97bca7a538 ~]# dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-10.noarch.rpm
Last metadata expiration check: 0:06:48 ago on Thu Jun 12 00:57:01 2025.
epel-release-latest-10.noarch.rpm                                            89 kB/s |  18 kB     00:00    
Dependencies resolved.
============================================================================================================
 Package                               Architecture   Version                    Repository            Size
============================================================================================================
Installing:
 epel-release                          noarch         10-6.el10_0                @commandline          18 k
Installing dependencies:
 selinux-policy-mls-extra              noarch         40.13.33-1.el10            crb                  475 k
 selinux-policy-targeted-extra         noarch         40.13.33-1.el10            crb                  779 k
Installing weak dependencies:
 dnf-plugins-core                      noarch         4.7.0-9.el10               baseos                44 k
 selinux-policy-extra                  noarch         40.13.33-1.el10            crb                   26 k
Transaction Summary
============================================================================================================
Install  5 Packages
Total size: 1.3 M
Total download size: 1.3 M
Installed size: 1.3 M
Is this ok [y/N]: 

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

Please continue any further discussion there.