[pkg-apparmor] Bug#1136786: Bug#1136786: apparmor: the fate of /etc/apparmor.d/disable (what is ... ) ?

[intrigeri]

Hi,

Alexandre Detiste (2026-05-15):
> I'm maintaining the cruft-ng tool that do Venn diagram operations
> between dpkg database (+ some heuristics) versus what's really there.

Thanks for caring!

> I see that /etc/apparmor.d/disable is there at first,
> but then there is a recurrent pattern of other packages
> trying to remove it.
>
> What's the best thing to do, in no prefrence order ?
>
>  1) drop the ball & drop the path from debian/apparmor.dirs
>  2) file a bug against each package attempting a rmdir
>  3) go the tmpfiles way so this dir got recrated at each boot anyway

It seems the `rmdir` commands you've found in postrm maintainer
scripts have been generated by dh-apparmor.

That's been the case since c9e3fbbf5e8b0b41f2b4076d8c4de66c04db5a7d,
which does not explain the rationale. Steve, do you know/remember why
we're attempting to delete /etc/apparmor.d/{disable,} every time
a package that uses dh-apparmor is purged? These directories are owned
by the apparmor package, so they'll be deleted if that one is purged,
which seems correct to me.

*If* there's currently no good reason for this, I think 2 other
approaches would be better:

  4) Long-term fix: remove the calls to rmdir in dh-apparmor, then
     wait for all packages to be incrementally updated

  5) Mitigation effective immediately: have the apparmor package ship
     a dummy file in /etc/apparmor.d/disable/, so that the call to
     rmdir is always a noop.

IMO we should do both.

I would happily review a MR on Salsa that implements either, or both,
of these approaches.

Cheers,
-- 
intrigeri