(In reply to Jakub Hrozek from comment #0)
> Description of problem:
> We would like to ship the Security Profiles Operator in OpenShift. One of
> the things it does is record syscalls that the workload is doing with the
> seccomp-bpf hook. So we'd like to include the seccomp-bpf hook in RHCOS, but
> because RHCOS tries to have a minimal footprint, we need to trim the
> dependencies down a bit. The most critical parts are really the python
> libraries (python is not allowed on RHCOS), but the fewer packages, the
> better in general.
> 
> It seems that the simplest way would be to not require bcc-tools but 
> instead Recommend them. That way, we'd retain backwards compatibility, while
> environments where the tools are not required could choose not to install
> them.

I'm not quite sure why bcc depends on bcc-tools: that seems unnecessary. I'll try to find if the were a valid reason for it, but my guess would be there never really was one.

> 
> Version-Release number of selected component (if applicable):
> bcc-0.20.0-1.el8.1.x86_64
> 
> How reproducible:
> 
> 
> Steps to Reproduce:
> 1. yum install bcc
> 2.
> 3.
> 
> Actual results:
> bcc installs bcc-tools which brings in python3-bcc, python3-netaddr,
> kernel-devel etc
> 
> Expected results:
> no python, no kernel-devel
> 
> Additional info:
> The openshift enhancement proposal can be find at
> https://github.com/openshift/enhancements/pull/745 and our team's tracker to
> include the seccomp hook can be found at
> https://issues.redhat.com/browse/CMP-927

(In reply to Jerome Marchand from comment #1)
> (In reply to Jakub Hrozek from comment #0)
> > Description of problem:
> > We would like to ship the Security Profiles Operator in OpenShift. One of
> > the things it does is record syscalls that the workload is doing with the
> > seccomp-bpf hook. So we'd like to include the seccomp-bpf hook in RHCOS, but
> > because RHCOS tries to have a minimal footprint, we need to trim the
> > dependencies down a bit. The most critical parts are really the python
> > libraries (python is not allowed on RHCOS), but the fewer packages, the
> > better in general.
> > 
> > It seems that the simplest way would be to not require bcc-tools but 
> > instead Recommend them. That way, we'd retain backwards compatibility, while
> > environments where the tools are not required could choose not to install
> > them.
> 
> I'm not quite sure why bcc depends on bcc-tools: that seems unnecessary.
> I'll try to find if the were a valid reason for it, but my guess would be
> there never really was one.

Great, thank you very much for looking into this. I wonder if you already plan on updating bcc in the near future so I could take time timing into account? Is there maybe already a z-stream update that this could be attached to or were you thinking 8.5?

(In reply to Jakub Hrozek from comment #2)
> Great, thank you very much for looking into this. I wonder if you already
> plan on updating bcc in the near future so I could take time timing into
> account? Is there maybe already a z-stream update that this could be
> attached to or were you thinking 8.5?

There should be no trouble for 8.5. There is no z-stream update planed atm.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (bcc bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2021:4205