Comment 13 for bug 1350598

@Pat, I think we actually want '8' for the phone. I mentioned what needs to happen in the description. I'll mention it again here:

'8' can be implemented now to improve the user experience:
"
> Sorry for not being clear. The idea is that when the phone says that
> there is an update, the user has to tap 'Install and Reboot'. The idea > is that before reboot (and therefore still in the unity8 session), we
> look inside what is downloaded, see if there are any policy changes. If
> there are, we extract them and then compile policy with a progress
> meter. The question I posed to you is how hard is it to look inside (or
> provide a manifest of changed packages) and extract what is needed to
> compile policy?

Ok. The update is available as a set of tarballs, available in a fixed
directory. It should be straightforward to check whether any of those
tarballs contains files matching a particular path. If you want to know
whether particular packages have changed, that would be a matter of
extracting the dpkg database and comparing. (We don't otherwise track the
packagewise delta between the images.)

A partial extraction of the tarball based on particular filenames is a
simple matter of tar arguments."

Basically, when the user presses 'Install and reboot". Essentially wherever the upgrade code lives it should do something along the lines of:
* download everything
* before installing, peak inside the rootfs to see if things changed, unpack the bits that changed, regenerate and recompile click policy with progress meter

I don't know where the upgrade code lives and/or if something needs to be done with unity8 for the progress meter. aa-clickhook would need to gain --with-progress.