Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
spec: Adjust selinux requirement for stable upstream releases
We make official upstream releases from packages built either in CBS or COPR. Neither of these environments offers any of the upstream clones of RHEL (AlmaLinux, Rocky Linux) as chroot environments - only CentOS Stream is available. This fact, combined with how `%{?selinux_requires}` macro works, makes our lives complicated. As part of `selinux-policy` installation we get a `/usr/lib/rpm/macros.d/macros.selinux-policy` file that has among others i.e.: ``` %_selinux_policy_version 36.14-1.fc36 ... %selinux_requires \ Requires: selinux-policy >= %{_selinux_policy_version} \ ... ``` The `%_selinux_policy_version` expands to the version of the `selinux-policy` package *that is installed in the environment where the RPM is built*. On CentOS Stream these RPMs are usually slightly ahead than their counterparts on the stable releases. Since we only have CentOS Stream chroots available for building RPMs, when we try to install such a package on a stable release, 'dnf' resolves the conflicts by simply picking a package version that's old enough to meet the 'selinux-policy' requirement. Ideally, packages for stable releases should be built in chroots based on stable releases. Since we don't have that option for now, let's define the `%_selinux_policy_version` by ourselves to a value that matches the version from the latest stable release. This patch should not affect deployments on CentOS Stream 9 in a any way. It may affect deployments on stable distros, as the SELinux policy compiled with a newer version of 'selinux-policy' package may not be backwards compatible with an older version. In current tests however everything worked fine. An alternative for this approach would be to force-install an older version of 'selinux-policy' package in the environment where 'ovirt-console' is built. This might not be possible due to some 'ovirt-vmconsole's build dependencies requiring a newer version. Even if it would work today, it could still be broken by an update of the dependent packages. Signed-off-by: Marcin Sobczyk <[email protected]>
- Loading branch information