Hi, Guido Günther wrote (29 Jun 2016 21:16:57 GMT) : > Rebuilding libvirt with above version leads to
> Installing new version of config file /etc/libvirt/qemu.conf ... > /var/lib/dpkg/info/libvirt-daemon-system.postinst: 147: > /var/lib/dpkg/info/libvirt-daemon-system.postinst: aa-enabled: not found > /var/lib/dpkg/info/libvirt-daemon-system.postinst: 172: > /var/lib/dpkg/info/libvirt-daemon-system.postinst: aa-enabled: not found > virtlockd.service is a disabled or a static unit, not starting it. FWIW, the fix for #828795 in 2.10.95-3 hides that error message. But then, if apparmor << 2.10.95-2 is installed, the profile won't be reloaded, which is itself a bug. > However aa-enabled is not available in 2.10-4 but only in 2.10.95-3 so > dh-apparmor needs to generate a versioned dependency via e.g. misc:Depends. So far, we've managed to avoid the need for packages that ship AppArmor profiles (and use dh-apparmor) to depend on the apparmor package itself. I'd like to keep it this way (e.g. for #702030), so here are the best cheap solutions I could think of: a. re-add the "aa-status --enabled" -based code as a fallback, that would be used when aa-enabled is not present. This should facilitate upgrades from Jessie to Stretch, as well as partial testing/sid upgrades, and can be dropped once Stretch and next Ubuntu LTS are released; b. move aa-enabled to a separate binary package, that dh-apparmor snippets can add a dependency on; c. simply revert to using "aa-status --enabled" in debian/debhelper/postinst-apparmor I'm personally tempted to go with (a), since it seems to give us the best of both worlds: a nicer implementation (compared to c), but without additional long-term maintenance costs (compared to b). Thoughts? In particular, I'd like to know what Ubuntu folks think about that, so we can pick a solution we can share :) Cheers, -- intrigeri
