Comment 22 for bug 876298

> We need to warn that the script can not do any dpkg operations and that the
> system may be in a state of flux when its run. This maybe a problem for e.g.
> update-alternatives calls, we need to think a bit more what to do here
> (Script-Run-After-Dpkg-Finished: register.sh maybe?).

I don't see any reason that we shouldn't be able to call update-alternatives - it's normal to run this both in a maintainer script context and outside of it, and running it from a triggered postinst or a cronjob should be no exception. FWIW, flashplugin-nonfree uses u-a and it's working reliably here.

>The other bit that is tricky is that we need to communicate failures in some
> way - or at least failures that are permanent. (for permanent e.g. more than
> 3 days). One way could be to create a update-notifier notification and to
> provide a cli tool like fetchme --show-queue or --show-incomplete. Plus a
> clear message in the apt log everytime its triggered what is missing and that
> it queued it for later if it has to.

So far what I've implemented is a notification popping up each time the script runs and fails to process the data. There's not yet any tracking of whether a download failure is "permanent" or a different error message in that case; nor is there particularly clear error output in the apt log yet.

An open question is how failing downloads should be handled once we've decided the error is permanent. Should we continue to try to download these and just avoid raising notifications about the failures? Or should we stop trying to download them at all? If we stop trying to download them, I guess we want a mechanism for users to forcibly retry these downloads once they've fixed their system.