The original problem this bug was about is gone. Actually, now that the multicache went in, we would instead install CACHEDIR.TAG in the cache-loc (/etc/apparmor.d/cache.d/CACHEDIR.TAG). It will apply recursively to all the actual cache sub-directories.
But the same practical problem comes back if using "apparmor_parser --purge-cache", which I would like to do on Debian scripts instead of having to maintain a shell implementation that does the same module it leaves CACHEDIR.TAG alone.
# touch /etc/apparmor.d/cache.d/CACHEDIR.TAG
# apparmor_parser --purge-cache
# ls /etc/apparmor.d/cache.d/CACHEDIR.TAG
ls: cannot access '/etc/apparmor.d/cache.d/CACHEDIR.TAG': No such file or directory
So, could "apparmor_parser --purge-cache" avoid deleting /etc/apparmor.d/cache.d/CACHEDIR.TAG?
The original problem this bug was about is gone. Actually, now that the multicache went in, we would instead install CACHEDIR.TAG in the cache-loc (/etc/apparmor. d/cache. d/CACHEDIR. TAG). It will apply recursively to all the actual cache sub-directories.
But the same practical problem comes back if using "apparmor_parser --purge-cache", which I would like to do on Debian scripts instead of having to maintain a shell implementation that does the same module it leaves CACHEDIR.TAG alone.
# touch /etc/apparmor. d/cache. d/CACHEDIR. TAG d/cache. d/CACHEDIR. TAG d/cache. d/CACHEDIR. TAG': No such file or directory
# apparmor_parser --purge-cache
# ls /etc/apparmor.
ls: cannot access '/etc/apparmor.
So, could "apparmor_parser --purge-cache" avoid deleting /etc/apparmor. d/cache. d/CACHEDIR. TAG?