dh_apparmor has no dh sequencer support

To be clear, I'm expecting that a debian/rules file that calls dh should not need to explicitly call dh_apparmor at all, and that AppArmor profiles will end up loaded before any corresponding service installed with dh_installinit is started.

Hey Robie,

I'm not particularly clueful when it comes to debhelper, but I don't really see how to accomplish this given what knowledge dh_apparmor has/doesn't have. It needs to know what profile(s) to create a local file for, as well as to reload; this is why the --profile-name argument is required to be passed to dh_apparmor.

I guess one possible way to do it would be to have an expected environment variable to look for, and have the function automatically inserted into the dh sequencer apply the profile based on that, but that wouldn't help the mysql case, as the sequenced dh_apparmor function wouldn't know to only apply the profile to the mysql-server-X.X package. Well, unless we got into complicated environment variables names or representations, which is even less appealing.

I guess another option would be some sort of profile manifest file(s) (not easyprof json manifests, but something akin to the .install, .docs, or .manpages manifests). But I'm also not sure how to do so in a backwards compatible way.

I'll give it some more thought.

To clarify, I mean that the existing dh_apparmor needs to be passed the profile name and potentially the package name as well as it has no means currently of discerning what those might be, which means there's no current way to get around requiring the packager to manually add the dh_apparmor call to the override_dh_install: target.

Thanks Steve.

Yes - I was thinking about something like a .apparmor file that tells dh_apparmor what it needs.

Without the dh sequencer, we're requiring two things:

1) For the packager to understand *where* to put the override
2) For the packager to specify information needed by dh_apparmor (the profile name)

Traditionally the dh sequencer eliminates the first, and the maintainer supplies the second via <package>.<dh_name> files.

Consider that if every dh_ helper worked in this current way, we'd be back to not having a dh sequencer.

For backwards compatiblity, how about falling back to the old behaviour on some combination of --profile-name and --manifest not being specified and the .apparmor file not being present?

And while we're talking of changing things, how about arranging it so that adding the profile to the .install file for dh_install is also not required? An example is dh_installinit - we don't install the init.d file and then give it to dh_installinit; it does the whole thing. Though that does get implied by "install" in the name. Maybe we should have dh_installapparmor which combines the two operations, and retain dh_apparmor for backwards compatibility and eventual deprecation?

How about:

debian/apparmor/usr.sbin.mysqld: <actual profile>

debian/mysql-server-5.6.apparmor:

debian/apparmor/usr.sbin.mysqld usr.sbin.mysqld

OR (both would work)

debian/apparmor/usr.sbin.mysqld

(profile name defaults to basename of path provided)

then, in debian/rules:

dh --with apparmor

OR (both would work)

dh_installapparmor at the appropriate time

OR (for backwards compatilibity)

dh_install # arranges /etc/apparmor.d/usr.sbin.mysqld to exist
dh_apparmor --profile=usr.sbin.mysqld

FWIW I went hunting for bug reports about this issue in response to https://github.com/snapcore/snapd/pull/6508 - if this were solved centrally in dh-apparmor, I expect that would benefit a number of packages over the long term.