On Fri, Apr 5, 2019 at 3:12 PM Dridi Boukelmoune
<dridi.boukelmoune(a)gmail.com> wrote:
Hello,
I maintain an selinux module package for el7, and recently came across
interesting macros [1] and in particular %selinux_requires that hides
the dirty detail and especially one that I missed when I set this up
back then.
Unfortunately, it appears to be provided by one of the packages it
BuildRequires itself:
> [vagrant@centos-7 ~]$ rpm --eval %selinux_requires
>
> Requires: selinux-policy >= 3.13.1-229.el7_6.9
> BuildRequires: git
> BuildRequires: pkgconfig(systemd)
> BuildRequires: selinux-policy
> BuildRequires: selinux-policy-devel
> Requires(post): selinux-policy-base >= 3.13.1-229.el7_6.9
> Requires(post): libselinux-utils
> Requires(post): policycoreutils
> %if 0
> Requires(post): policycoreutils-python-utils
> %else
> Requires(post): policycoreutils-python
> %endif
>
> [vagrant@centos-7 ~]$ grep selinux_requires
/usr/lib/rpm/macros.d/macros.selinux-policy
> # %selinux_requires
> %selinux_requires \
> [vagrant@centos-7 ~]$ rpm -qf /usr/lib/rpm/macros.d/macros.selinux-policy
> selinux-policy-3.13.1-229.el7_6.9.noarch
So when I try to build this in mock with the default build root I get
this error:
> error: line 99: Unknown tag: %selinux_requires
I think I found the solution here:
https://fedoraproject.org/wiki/PackagingDrafts/SELinux_Independent_Policy
BuildRequires: selinux-policy
%{?selinux_requires}
This way its expansion can be deferred at rebuild time, I suppose. But
don't we miss the other BuildRequires tags in this case?
I will give it a try.
> I noticed that mock runs with SELinux disabled:
>
> > Start: init plugins
> > INFO: selinux disabled
> > Finish: init plugins
>
> So I don't know whether it would be a problem to add it to the build root.
>
> What should be the way forward?
>
> a) can it be added to the default build root?
> b) should it be shipped by a different package part of the default build root?
> c) can I add it to the build root during the --buildsrpm execution?
>
> If anything, I'd like to 1) avoid forking the default epel7 configuration
> and 2) manually expand the macro in my spec, although this is what I'm
> leaning towards right now. The simple reason being that I have an up
> to date mock on f29 but other parties involved my be running an ancient
> mock on other systems... Unless solution b lands in epel7, in which case
> I'm not sure which package should own the macros and get the bug report.
>
> Thanks,
> Dridi
>
> [1]
https://github.com/fedora-selinux/selinux-policy-macros/