We cannot have inconsistent requires amongs the architectures. Otherwise
the koji build fails with:
BuildError: mismatch when analyzing
openscap-containers-1.2.6-2.fc24.noarch.rpm, rpmdiff output was:
error: cannot open Packages index using db5 - Permission denied (13)
error: cannot open Packages database in /var/lib/rpm
error: cannot open Packages database in /var/lib/rpm
added REQUIRES atomic
This is pragmatic choice. (Upcomming) OpenSCAP-Daemon will need to
import openscap-containers python fragments. We decide to fail in
run-time when atomic features of OpenSCAP-Daemon are used on other
architectures.
The only reason is that /usr/bin/oscap-docker file has been previously
released (for 2 months) in openscap-utils package. On the other hand
architecture of oscap-docker changed and now requires atomic to run.
Update to the latest upstream. Upstream dropped selinux policy due to
bug rhbz#1209969. We should drop the sub-package as well. However, we
cannot obsolete selinux noarch sub-package from base package that is
arch. Otherwise we risk for things to slip through cracks as they did
with rhbz#1028706. Ideas?
Also introduce new probe for symlink_test.
The symlink libopenscap_sce.so is supposed to be consumed
by linker, but not by a run-time. The symlink is not assured
to point-out to the latest shared object (otherwise libtool
authors would not introduced such symlink).
This fix should enable use of SCE without openscap-engine-sce-devel
package installed.
The scap-secrity-guide package will bring this directive instead.
Addressing (rhbz#1028706):
openscap update incorrectly pulls in piles of 32bit packages
