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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
