Control: tag -1 - moreinfo Heya,
High-level note: I lack knowledge to evaluate this proposal in terms of debhelper integration. I'd be grateful if Niels could take a look :) Andrej Shadura (2021-02-05): > I’ll start with explaining the idea. Awesome, thanks, it helps a lot! > The status quo is: > * Each profile needs to be installed manually > * dh_apparmor needs to be told which profiles to use > * dh_apparmor needs to be told to only run on specific packages > * override_* or execute_after_* are mandatory We're on the same page here. More generally, it is seriously sub-optimal that using dh_apparmor requires programming, as opposed to using a declarative syntax (for non-obvious cases) and auto-detection (for obvious cases). > My proposal is: > * For dh compat level <= 13: > - allow running dh_apparmor without arguments; > - without arguments, scan binary packages for apparmor profiles and use > their names automatically > - dh_apparmor can be enabled with --with=apparmor or B-D: > dh-sequence-apparmor > - without arguments, dh_apparmor only generates maintainer scripts for > packages with apparmor profiles > - with arguments, dh_apparmor does everything like it does now, no changes > > * For dh compat level 14: > - as above, but with arguments, only generate maintainer scripts for the > corresponding binary packages > The above will allow processing apparmor profiles without extra > rules in d/rules, while maintaining compatibility with > existing packages. I understand that at a higher level, for the simplest cases this translates into something like this: As a maintainer When I ship an AppArmor profile in a binary package And I enable the dh_apparmor debhelper sequence Then the dh_apparmor machinery Does The Right Thing™ without further configuration As a maintainer, I think it's awesome! It may be worth specifying behavior for one corner case: what happens if a "-p PACKAGE" argument is passed? Possible improvements for further iterations, definitely not blocking this plan IMO, i.e. food for future thought: - Either drop support for --profile-name or, if for some reason it's still needed, support declarative syntax to configure it. - Consider enabling dh_apparmor by default (and provide means to disable it, either entirely or on a per-profile basis with declarative syntax). Cheers!