Hi,

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

So we have either extraneous files dropped around by slopy admin/package
 maintainers "unexplained" of misteriously missing dpkg files "missing.

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.

https://sources.debian.org/src/apparmor/4.1.7-2/debian/apparmor.dirs


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

Greetings

Alexandre


$ sudo cruft -R ./ruleset
cruft report: ven 15 mai 2026 22:32:34
---- missing: dpkg ----
        /etc/apparmor.d/disable
---- unexplained: / ----
        /etc/apt/apt.conf.d/10periodic
        /etc/apt/preferences.d/tchet
        /etc/cron.daily/build
        /usr/bin/versions
        /usr/lib/python3/dist-packages/colorclass/py.typed
        /usr/lib/python3/dist-packages/omg/__init__.pyi
        /usr/lib/python3/dist-packages/omg/py.typed
        /usr/lib/systemd/user/cron-user-mail@.service
        /usr/lib/x86_64-linux-gnu/libpicohttpparser.so.1

end.

$ grep /etc/apparmor.d/disable /var/lib/dpkg/info/* | grep rmdir
/var/lib/dpkg/info/akonadi-server.postrm:    rmdir /etc/apparmor.d/disable 2>/dev/null || true
/var/lib/dpkg/info/akonadi-server.postrm:    rmdir /etc/apparmor.d/disable 2>/dev/null || true
/var/lib/dpkg/info/akonadi-server.postrm:    rmdir /etc/apparmor.d/disable 2>/dev/null || true
/var/lib/dpkg/info/akonadi-server.postrm:    rmdir /etc/apparmor.d/disable 2>/dev/null || true
/var/lib/dpkg/info/apparmor.postrm:    rmdir /etc/apparmor.d/disable 2>/dev/null || true
/var/lib/dpkg/info/apparmor.postrm:    rmdir /etc/apparmor.d/disable 2>/dev/null || true
/var/lib/dpkg/info/game-data-packager-runtime.postrm:    rmdir /etc/apparmor.d/disable 2>/dev/null || true
/var/lib/dpkg/info/ioquake3.postrm:    rmdir /etc/apparmor.d/disable 2>/dev/null || true
/var/lib/dpkg/info/ioquake3-server.postrm:    rmdir /etc/apparmor.d/disable 2>/dev/null || true
/var/lib/dpkg/info/isc-dhcp-client.postrm:    rmdir /etc/apparmor.d/disable 2>/dev/null || true
/var/lib/dpkg/info/libreoffice-common.postrm:    rmdir /etc/apparmor.d/disable 2>/dev/null || true
/var/lib/dpkg/info/libreoffice-common.postrm:    rmdir /etc/apparmor.d/disable 2>/dev/null || true
/var/lib/dpkg/info/libreoffice-common.postrm:    rmdir /etc/apparmor.d/disable 2>/dev/null || true
/var/lib/dpkg/info/libreoffice-common.postrm:    rmdir /etc/apparmor.d/disable 2>/dev/null || true
/var/lib/dpkg/info/man-db.postrm:    rmdir /etc/apparmor.d/disable 2>/dev/null || true
/var/lib/dpkg/info/rtcw.postrm:    rmdir /etc/apparmor.d/disable 2>/dev/null || true

Hi,

Alexandre Detiste (2026-05-15):

Thanks for caring!

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,