Comment 1 for bug 876298

[11:03] ev: so we have an interesting problem around apt/dpkg
[11:03] ev: if the flashplugin installer package fails to get its payload from archive.canonical.com, the package installation fails. Yesterday, a lot of ubiquity installs failed because archive.c.c was under heavy load and returning 503 errors. Ubiquity tries to install the flash plugin as part of the "3rd party extras checkbox". If the package install fails, ubiquity fails, as dpkg will be in a bad state.
[11:03] ev: What are your thoughts on how to solve this?
[11:03] ev: James Troup suggested a canary in the preinst. A few of us came up with the idea of extending the package metadata to allow specifying a payload that can be locally cached by ubiquity or apt-get --download-only, as this is a problem for the Microsoft fonts as well
[11:03] ev: congratulations on the release, by the way
[11:03] ev: (if ubiquity failed to grab the payload, it wouldn't try to install the package)
[11:06] mvo: along the same line, we have bug #859373 where network-manager helpfully shutsdown networking during the upgrade (well, wifi, but still)
[11:07] ev: yay
[11:07] mvo: its a good question how to fix it, all preinst/postinst trickery will not really work because what we want is that the failure is not fatal but something like transient (until we have network again)
[11:08] mvo: but with the current dpkg we can either mark installed or failed, there will be no retry option
[11:08] ev: also, it would be nice to have a way to queue up retries
[11:08] ev: as we have language packs and whatnot that can't always be installed from ubiquity
[11:09] ev: when there's no network initially
[11:09] ev: and it would be great if we could mark them somewhere and have them show up in update-manager on first boot
[11:09] mvo: maybe we simply need a extension where packages just register a url and a script
[11:09] mvo: and something outside of the pakcage will then take care of it
[11:09] mvo: dpkg will consider it installed because the relevant data is on the system
[11:09] mvo: and that "other" can re-try, download etc at its leisure
[11:09] ev: hmm, could work
[11:10] mvo: hm, queing up packages too is interessting
[11:10] ev: yeah, right now it's a mess
[11:10] mvo: indeed
[11:10] ev: we have that update notifier dialog for language packs
[11:10] ev: which is less than ideal
[11:11] mvo: *FAR from it*
[11:11] mvo: yeah
[11:11] ev:
[11:11] mvo: ok, so two new bits: a) download my external resource framework b) queue pkg install for later
[11:11] ev: indeed
[11:11] mvo: we could abuse apt-get dselect-upgrade for the later
[11:12] ev: oh nice
[11:12] ev: I was unaware of that little gem
[11:14] mvo: it means we mess with the dselect states, but I guess only colin and the other remaining dselect users will care
[11:14] mvo: s/users/user/
[11:14] ev: lol
[11:14] ev: I'm sure they'll live
[11:16] mvo: yeah
[11:22] mvo: I get some lunch now and then I check out (b), but I think that is really straightforward with 'echo "2vcard install" | dpkg --set-selections' and u-m should not really need much changes for this either
[11:22] ev: great! thanks!
[12:45] mvo: I commited code to u-m in trunk that will honor the dpkg selection state, lets see what fallout this will generate, I have kvm set to "i" for some reason for example
[14:35] ev: woohoo
[14:35] ev: cheers