On 6 June 2016 at 20:03, Seth Arnold <seth.arn...@canonical.com> wrote: > > On Mon, Jun 06, 2016 at 08:49:46PM -0300, Felipe Sateler wrote: > > Control: tags -1 patch > > > > On Sat, 22 Aug 2015 17:04:38 -0300 fsate...@debian.org wrote: > > > Hi, > > > > > > Your package apparmor has an initscript that is enabled in runlevel > > > S, but it does not provide a corresponding systemd service unit. > > > > Please find attached a unit that wraps the currently existing init > > script. Proper integration (which I understand is being worked on) can > > be added later. > > Felipe, I really liked the idea of your comment on the corresponding > upstream bug: > https://bugs.launchpad.net/apparmor/+bug/1503762 > Your comment (in isolation): > https://bugs.launchpad.net/apparmor/+bug/1503762/comments/4 > > Is there a strong enough reason to ship the wrapping-the-sysv .service > file? That feels like an odd step to take.
I am not an apparmor user, so I cannot judge the correctness of the new service file, or test that it works fine in sufficient configurations. Moreover, the init script appears to do a lot more work than just invoke `/usr/sbin/apparmor_parser -r $paths`, how can I be sure the new unit would be equivalent? Therefore I stuck with the minimal approach: make apparmor ship a file similar to what is currently being generated by systemd. This has a much smaller chance of being broken. I hope this explains. -- Saludos, Felipe Sateler
