Comment 2 for bug 1217098

Here's where I'm stuck at the moment.

Let's say the u/i calls CheckForUpdate() and then DownloadUpdate() (unless automatically downloading) and everything succeeds. So far so good.

But then, the user doesn't click on 'apply' (i.e. ApplyUpdate()) and s-i-dbus idle-exits.

Now sometime in the far future, the user does click on Apply and the u/i calls ApplyUpdate(). A new s-i-dbus will get activated, but it shares none of the state of the previously exited process. Turns out this state is critical to determining whether an update can be applied or not. I haven't been able to figure out a good way to restore that state that doesn't regress a bunch of other tests.

One possible solution would require a bit more interaction with the u/i. On the far-future ApplyUpdate(), the u/i would get an error return (e.g. a non-empty string). It would then have to re-issue the CheckForUpdate() and DownloadUpdate() before it could call ApplyUpdate(). One nice thing though is that if the same upgrade path is still valid, and the data files that were previously downloaded were still valid (i.e. checksums and signatures still match, no invalidating blacklist was added), then those data files will not be re-downloaded.

So the second CFU/DU should be much quicker.

I wonder if that would be acceptable?