intrigeri: > Update: the systemd unit that's used in openSUSE and Arch Linux was > imported upstream > (https://gitlab.com/apparmor/apparmor/merge_requests/81)
> Next step: check if it does everything Debian needs. While packaging 2.13 I've cleaned up lots of obsolete cruft and simplified /lib/apparmor/functions (that does the bulk of the work for the initscript) quite a bit. I'll push to Vcs-Git later this week after some more testing and history cleanup. This was a first necessary step for me to understand why exactly we still have so much distro-specific code in there. AFAICT by looking at the remaining code, the only bits we have that are not supported by the upstream systemd service add support for: - an additional profiles directory for snaps (/var/lib/snapd/apparmor/profiles). The only hits apt-file and codesearch give me for /var/lib/snapd/apparmor/profiles are in some test cases in src:snapd. No package creates that directory AFAIK. I suspect that not supporting this extra profiles directory on Debian will have no impact on existing use cases. - containers with a stacked policy AFAIK the only implementation that takes benefit of this feature is LXD, which is not in Debian. ⇒ It looks like dropping this would not harm Debian users. So, I'll try the upstream systemd unit file on Debian and if it works well I'll replace the one we currently ship with it. Regarding snaps and stacked policy: IMO the best way forward is for Ubuntu to improve the upstream systemd profile (and the corresponding shell functions library) so that they support these features out-of-the-box on all distros. Note that I have no plans to stop installing the initscript nor to delete the code we have to support these features during the Buster cycle; I only want to stop using it when running systemd; so until these extra features are upstreamed, Ubuntu just has to keep installing our current systemd unit file, as part of their delta, instead of the upstream one. Thoughts? Cheers, -- intrigeri