This will allow package maintainers to automatically create $pkgname-apparmor-profile sub-package, with apparmor profiles for their package (put in
TSC has declined the request for alpine specific apparmor profiles due to increased burden of maintenance for now (tsc#26 (closed)). I believe supporting it is still on table, but is not planned for foreseeable future. This MR is in spirit of adding apparmor support incrementally. It will allow package maintainers to provide apparmor profiles, while keeping the burden of maintenance distributed among them. The apparmor-profiles package needs some maintenance (which I'm offering to commit to), hence this MR is in Draft state.
Request for comments
- Is this the right direction to support AppArmor in Alpine?
- Should we allow package maintainers to start packaging apparmor profiles (while working with upstream)?
aaprofappropriate names for subpackage and split function respectively?
Once this is accepted we need to add a trigger for apparmor-profiles that (un)loads policies that are (de)installed or upgraded by individual packages.
Note: This is my first MR to abuild (and alpine infrastructure in general). Let me know if I got anything wrong.