Comment 5 for bug 1503762

I agree to Felipe here, there's not that much gain from providing another indirection with /etc/default/apparmor. systemd unit drop-ins can be put into /lib/systemd/system/ and thus shipped by packages like lxc-android-config without the hassle of conffiles or the user potentially breaking them. *If* you really want an /etc/default/apparmor which defines $APPAMOR_SEARCH_LIST, then I suggest to add

  ConditionPathExists=/etc/default/apparmor

to guard against the admin removing the conffile. (But this is just a tangent -- I still don't recommend adding a conffile for this; this is *not* configuration in the "admin can muck around with that" sense!)

I also agree that using templates seems like overkill here. They make restarting/reloading a much bigger hassle, you might run into issues with parallelization, and you'll need a generator to actually instantiate them. Iterating over a list of files and feeding them to apparmor_parser is so simple that this can be much more easily be done directly.

In terms of code management, I suggest to moving out the common code of /etc/init.d/apparmor and apparmor.service into /lib/apparmor/functions (or perhaps a different file) and calling it from both the init.d script and the systemd unit. I. e. what the above /usr/bin/apparmor_load.sh does, just perhaps not in $PATH (unless it actually makes sense for the user to call it directly).