Comment 2 for bug 1460152

This should be fixed with:
  http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/revision/1120

I do however wonder if apparmor_parser should set the mtime of the cache file to the mtime of the original file. The current behavior will also break e.g. restore of backups to /etc/apparmor.d/

Assume that:
- /etc/apparmor.d/usr.bin.foo gets backuped
- admin edits usr.bin.foo and breaks it
- admin re-boots
- admin runs /usr/bin/foo and it fails
- admin restores /etc/apparmor.d/usr.bin.foo from a backup that will also restore all meta-data
-> now the cache never gets updated and /usr/bin/foo is broken because the cache is newer than the mtime of the etc/apparmor.d/usr.bin.foo (it would have to be touched to trigger a cache rebuild)

One fix would be to use the same mtime in the cache as in the original and re-generate the cache if the mtimes differ. Or just encode the mtime of the original in the cache data structure.