Avoid re-downloading data files

I think the way I'm going to handle this is like so:

When you re-check for an update, it will re-download everything up to the data files. E.g. it will look for a blacklist, update keyrings, grab the channels.json and index.json files, and re-calculate the upgrade path. If the data files in the winning upgrade path are already downloaded *and* their gpg signatures are still valid, then we can avoid downloading the data files again. We can download only the data files that are missing, or for those with broken signatures (which probably means corruption more than attack).

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?

Hey Barry,

That doesn't sounds like a good way of designing the API. The UI shouldn't have to know if this errors is because the daemon timed out and wasn't able to restore its state or because something else on the system is screwed.

For instance, let's imagine we want to report automatically when ApplyUpdate() failed (in addition to the feedback from the user). So, we have to take into account the case "the daemon timeouts and this is excepted to fail" with "there is a real issue on the system"?

On Oct 25, 2013, at 07:03 AM, Didier Roche wrote:

>That doesn't sounds like a good way of designing the API. The UI
>shouldn't have to know if this errors is because the daemon timed out
>and wasn't able to restore its state or because something else on the
>system is screwed.
>
>For instance, let's imagine we want to report automatically when
>ApplyUpdate() failed (in addition to the feedback from the user). So, we
>have to take into account the case "the daemon timeouts and this is
>excepted to fail" with "there is a real issue on the system"?

Yeah, I was hoping for an easy way out, but I agree it sucks. ;)

Another possible easy way out would be to not timeout-exit when an upgrade is
fully downloaded and ready to be applied. Of course, the process could exit
for any number of reasons, but waiting to click 'Apply' will probably be the
most common reason.

I'll need to think about this more because it's going to be tough to fix.

I've finally solved this, but a minor API change will be necessary. See the mailing list for details.