#370 Depend on rpm-plugin-selinux *or* ostree
Opened 7 months ago by walters. Modified 6 months ago
rpms/ walters/selinux-policy rpm-or-ostree  into  rawhide

file modified
+1 -1
@@ -71,7 +71,7 @@ 

  BuildRequires: systemd-rpm-macros

  Requires(pre): policycoreutils >= %{POLICYCOREUTILSVER}

  Requires(post): /bin/awk /usr/bin/sha512sum

- Requires(meta): rpm-plugin-selinux

+ Requires(meta): (rpm-plugin-selinux if rpm-libs)

  Requires: selinux-policy-any = %{version}-%{release}

  Provides: selinux-policy-base = %{version}-%{release}

  Suggests: selinux-policy-targeted

We support two ways to update the operating system:

  • /usr/bin/rpm (and dnf etc.) where SELinux labels are
    computed and written client side
  • ostree (and other image-based systems) where SELinux labels
    were computed server side.

In the ostree case, I'd like the ability to generate smaller
images that do not even have rpm installed.

This dependency is the primary blocker to that. Now that
RPM supports these "alternative" conditionals, it's easy to do.

(TODO: Maybe this would actually also make sense in the RPM package;
we could do Requires: (rpm-plugin-selinux if selinux-policy) perhaps?)

One question I had that I wasn't certain about: do depsolvers prefer the first entry in these booleans?

I did have a worry that people building images that happen to include ostree but want to update via rpm might have rpm-plugin-selinux drop out.

Clearly we could at least do a Recommends in the rpm package e.g.

diff --git a/rpm.spec b/rpm.spec
index ae77952..7e68e2c 100644
--- a/rpm.spec
+++ b/rpm.spec
@@ -54,6 +54,7 @@ Requires: popt%{_isa} >= 1.10.2.1
 Requires: curl
 Conflicts: systemd < 253.5-6
 Obsoletes: python2-rpm < %{version}-%{release}
+Recommends: (%{name}-plugin-selinux if selinux-policy)

 # XXX generally assumed to be installed but make it explicit as rpm
 # is a bit special...

(TODO: Maybe this would actually also make sense in the RPM package;
we could do Requires: (rpm-plugin-selinux if selinux-policy) perhaps?)

Or maybe change this patch to Requires(meta): (rpm-plugin-selinux if rpm)? That seems to make more sense logically.

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci
https://fedora.softwarefactory-project.io/zuul/buildset/7595af803db4405399b7a3db0a6a67e7

rebased onto d395198cfd377a63022fc21f166ab411e22192f9

7 months ago

Or maybe change this patch to Requires(meta): (rpm-plugin-selinux if rpm)? That seems to make more sense logically.

Yes, I think you're right; done!

I only very lightly tested the first version works for my use case, will retest with the latest change now.

This could also use some extra testing with package based workflows to verify they continue to do the right thing, and that the package remains across upgrades etc.

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci
https://fedora.softwarefactory-project.io/zuul/buildset/dfd5c3b8dc12499fa5ade9da0730061b

The dependency should really be on rpm-libs rather than rpm. Currently it's not possible to install one without the other but that could change.

The dependency should really be on rpm-libs rather than rpm.

Hmm...in case someone wanted to install a system with e.g. dnf but not rpm? Or if that's not it just for posterity can you explain what the use case would be?

rebased onto 80fd14e

6 months ago

Updated to use rpm-libs

Build failed. More information on how to proceed and troubleshoot errors available at https://fedoraproject.org/wiki/Zuul-based-ci
https://fedora.softwarefactory-project.io/zuul/buildset/decc5171c0e645d28eb530aebfeffadb

Yes, because somebody might want to install just dnf, or some other higher level package manager for that matter. It's probably not a configuration any "normal" user wants, but in the container space with every byte counting, who knows. Of course, to enable that we'd need to split the main rpm package into two (something I've been considering for a while).

OK first time I've tried to really dig through Zuul/STI logs but the failures here don't look obviously related?

OK first time I've tried to really dig through Zuul/STI logs but the failures here don't look obviously related?

The tests failures do not seem to be related to the suggested changes.

Metadata