Thanks Vit!
That clears it up. It sounds like if we want to support multiple RHEL
minor releases *and* CentOS Stream, we're going to have to compile in
a buildroot that has the oldest version of selinux-policy that we want
to support.
- Ken
On Thu, Jan 28, 2021 at 2:00 AM Vit Mojzis <vmojzis@xxxxxxxxxx> wrote:
>
> Hi,
>
> the exact version requirement is in place to avoid incompatibility
> between the policy on the target system (system you want to install the
> module on) and the custom policy module.
>
> Lets call the policy used to compile your module "A", policy on the
> target system "B" and your custom module "C".
>
> C can be incompatible with B if A contains a new definition (object
> class, permission, type or boolean) that is not present in B and the
> newly defined name is used in your module (e.g. because of an interface
> used in your module). The incompatibility will prevent installation of
> your module ("semodule -i" will fail).
>
> Please see [1] to get an idea of when you can expect new definitions to
> appear in RHEL policy.
>
> Depending on an unversioned selinux-policy-base can therefore cause
> problems not only when installing policy compiled on RHEL to a CentOS
> system, but also when installing it on the same version of RHEL, with
> outdated system policy.
>
> I would at least suggest using dependency on some reasonably recent
> fixed version of selinux-policy-base, and testing each new build of your
> module on a system with that fixed version of selinux-policy-base.
>
> However, it would be best to avoid cross-sytem installations.
>
> Hope this helps.
>
>
> Vit
>
>
> [1] - https://access.redhat.com/articles/4854201
>
> On 1/27/21 6:30 PM, Ken Dreyer wrote:
> > Hi folks,
> >
> > Many applications ship their own "-selinux" sub-package. These
> > subpackages usually set a minimal dependency on the exact
> > selinux-policy version in the buildroot.
> >
> > In Ceph's case, we have:
> >
> > Requires(post): selinux-policy-base >= %{_selinux_policy_version}
> >
> > This version requirement causes problems in two scenarios:
> >
> > 1. If we build Ceph on CentOS Stream, the ceph-selinux package will be
> > uninstallable on RHEL.
> >
> > 2. If we build Ceph on the latest RHEL 8, the ceph-selinux package
> > package will be uninstallable on RHEL 8 EUS.
> >
> > Is it safe to drop the exact version requirement here and just depend
> > on an unversioned "selinux-policy-base"?
> >
> > I can't find any official Fedora Packaging Guideline on this. I opened
> > https://tracker.ceph.com/issues/49034 to track this in Ceph upstream.
> >
> > - Ken
> > _______________________________________________
> > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
