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