Update Manager should time out on debconf questions

[Ted Gould]

I think that the upgrade should have timeouts on the various debconf questions that might happen during an upgrade. In this way if someone (let's say me) were to start an install (and let's say go to lunch) they wouldn't come back with the install almost at the beginning.

Here's how I think it should work. I think that if asked a question, that question should have a 1 minute timeout. If the question is not responded to, update manager should fail the install of that package. Then it should continue to install packages that aren't dependent on that one pushing the current package as far back in the queue as possible. While this wouldn't allow for a complete install, but it would allow for it to get much more complete if it is unattended.

[Hugh Saunders (hughsaunders)]

I would suggest adding command line options to do-release-upgrade; --force-yes and --force-current. This would allow do-release-upgrade to answer questions of this form:

"Configuration file `/etc/gdm/Xsession'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ? Your options are:
    Y or I : install the package maintainer's version
    N or O : keep your currently-installed version
      D : show the differences between the versions
      Z : background this process to examine the situation
 The default action is to keep your current version."

Without interrupting the upgrade process.

Maybe there is already a way of doing this?

[Boris Dušek (dusek)]

I agree. I am currently managing remotely 15 clients and doing do-release-upgrade and having to wait to answer even 1 question on all of them is quite a nuisance. I agree that there should be options as Hugh suggested so that the admin can choose the behavior. I would also suggest an option to specify whether or not to reboot the machine. All in all, ideally one would run the do-release-upgrade with the right options and leave it right after starting it and come back a few hours later with the machine rebooted into the release-upgraded system.

[Boris Dušek (dusek)]

For the record, the questions I answered (and how I answered them) when doing do-release-upgrade from Maverick to Natty (I write just from memory, the questions were definitely not worded exactly as I write them):

 * do-release-upgrade over ssh is not recommended. Do you want to continue? (my answer: y)
 * alternative ssh will be launched on port 1022 in case something goes wrong with current ssh on port 22. OK? (my answer: y)
(now 5 minutes of calculating package dependencies)
 * this will upgrade to natty. X packages will be upgraded, Y removed etc. etc. Proceed? (my answer: y)
 * standard upgrade questions about modified configuration files - /etc/default/grub in my case
 * X packages are no longer needed, Y packages are no longer supported. Remove them? (my answer: y)
 * To finish the upgrade, you need to restart. Restart now? (my answer: y)

So if I could avoid answering all those questions, I could do the do-release-upgrade unattended.