Bernhard Schmidt: > It would be great if dh-apparmor could check the basic syntax > of the AppArmor policy included in the package and abort the build.
I've thought a bit more about it and I see a few issues with this proposal: 1. dh-apparmor will need a dependency on apparmor, so that apparmor_parser is available; incidentally this will guarantee that commonly used abstractions are available. 2. It will require changes to in at least a few packages so they don't start to FTBFS: say the AppArmor profile one wants to ship in the package depends on an abstraction shipped in another package, e.g. apparmor-profiles-extra (I've just seen one example today: src:surf). Then a build-dep on that other package must be added, otherwise the profile won't compile. I don't know how many packages are affected. I would start with: https://codesearch.debian.net/search?q=%23include+%3Cabstractions%2F … and then filter out all abstractions shipped in the apparmor package. 3. Packages that themselves ship abstractions will require special handling: dh_apparmor cannot guess what -I parameter it should pass to apparmor_parser in order to make these abstractions available to the parser. All this is doable but requires quite more work (and risks) than I thought initially. I'm starting to think that it would be vastly easier to do that via autopkgtests: once the binary package that ships AppArmor policy is installed, one can assume that the abstractions it needs are there as well, which avoids #2. And no need to pass -I, which avoids #3. Ideally dh_apparmor would "simply" (sic) generate these tests in debian/tests/, somehow. I don't know if that's possible. But perhaps it would be good enough to: - provide the tooling to make it really simple to enable these tests - add a Lintian check that warns when these tests are not enabled for a package that ships AppArmor policy As a bonus, this approach will trigger autopkgtest runs on ci.debian.net for all packages that have this test enabled, whenever src:apparmor is updated (because this test will need a dependency on apparmor), which would be great. Thoughts? Too bad our CI runs by default in a container environment where we cannot load AppArmor policy. Otherwise the test would boil down to "check that installing the package did load the profile successfully". Cheers, -- intrigeri