[libvirt] [PATCH] virt-aa-helper: handle more disk images

[Cedric Bosdonnat]

On Thu, 2017-12-21 at 12:10 +0100, intrigeri wrote:
> 1. Doing the same for usr.sbin.libvirtd?

Is there any real good for the user to have local changes for the libvirtd profile?

> The apparmor_profiles_local_include.patch Debian patch does the same
> for usr.sbin.libvirtd:
> 
> diff --git a/examples/apparmor/usr.sbin.libvirtd b/examples/apparmor/usr.sbin.libvirtd
> index fa4ebb3..5505bf6 100644
> --- a/examples/apparmor/usr.sbin.libvirtd
> +++ b/examples/apparmor/usr.sbin.libvirtd
> @@ -90,4 +90,7 @@
>  
>     /usr/{lib,lib64,lib/qemu,libexec}/qemu-bridge-helper rmix,
>    }
> +  
> +  # Site-specific additions and overrides. See local/README for details.
> +  #include <local/usr.sbin.libvirtd>
>  }
> 
> Cédric and others, what about upstreaming this as well?

We don't have it yet in the openSUSE/SLES packages, so feel free to upstream it.
> 
> 2. Impact on packaging for distros that were already managing this
>    local file themselves & differently
> 
> … i.e. I guess mostly Debian and derivatives, that use dh_apparmor.
> 
> If I got the build system changes right,
> local/usr.lib.libvirt.virt-aa-helper will be created at installation
> time so in practice it'll be shipped by distro packages.

Hum... In any case in a spec file (and I suppose for you too) that file can be
removed before creating the package. I'm not feeling good about including
files in the upstream profiles that don't exist.

> I *think* it's not a problem with dh_apparmor because the generated
> postinst scripts only manage that file if it does not exist yet (so it
> should be a no-op if dpkg has already installed it), and similarly the
> code for purging in postrm should work just fine if dpkg has already
> deleted it.

We mark all files in local with %config(noreplace), not sure what is best ;)

--
Cedric