Comment 3 for bug 1371574

I've made some progress on this. It is all however excruciatingly delicate, and this is not the first time that I have had to fix bugs of this general nature. I'm beginning to wonder if I should be taking a different approach. The whole problem here is that system hooks may only be attached to by a single instance of any given package version; this leads to the requirement that the AppArmor profile must point to just the right instance, and we often run into trouble (of the "launching application results in blank screen" kind) when trying to move packages around between databases in various ways. Even with regression tests, I'm worried that if I whack this mole it's still going to pop up somewhere else. It's not clear that all the requirements are truly soluble given the current design.

A more comprehensive answer to this category of problems, then, would involve a slight tweak to the design of system hooks, though fortunately an entirely backward-compatible one:

 * We add a new substitution to the hook Pattern field that expresses which database a package is in (the practicalities seem to suggest that a mangled version of its path would be easiest, so ${db-path} expanding to "usr_share_click_preinstalled" etc.).
 * When this substitution is present, "click hook" would start running system hooks for all instances of every package version.
 * click-apparmor could then add that to its .hook file once it's ready, perhaps becoming "Pattern: /var/lib/apparmor/clicks/${db-path}/${id}.json", or a flat structure if that's easier. It would need to adjust its handling of /var/lib/apparmor/{clicks,profiles}/ to cope with this, of course, and the first system image upgrade with the new version of click might have to rebuild all profiles on startup unless it's very clever, but that's comparatively minor.
 * Now that profiles depend on the database path, aa-exec-click would need to change its lookup to depend on the click database containing the requested executable. Some care would be needed to make sure this doesn't slow down application startup and make Ricardo cry; ubuntu-app-launch's desktop hook could perhaps help with this, although that may not be necessary.

The result of this would be much easier to deal with in click, and would be free of corner cases where there isn't obviously a single correct answer.