Make it easy to enable unattended-upgrades

Registered by Colin Watson on 2011-05-03

Make it easier to enable unattended-upgrades.

Blueprint information

Not started
Steve Langasek
Michael Vogt
Michael Vogt
Series goal:
Accepted for oneiric
Milestone target:

Related branches



Work items:
provide dbus/polkit support for enabling unattended-upgrades in minimal chunks mode (check if lp:~kubuntu-packagers/software-properties/dbusworker can be used): INPROGRESS
write progress information from unattended-upgrades to /var/run/unattended-upgrades.progress: DONE
investigate if the shutdown plymouth splash works reliable: TODO
display progress info in u-n shutdown (instead of current "please wait" msg): DONE
[mpt] get design input in where the "apply in the background" button should be placed (update-manager main window, software-properties): DONE
[mpt] get design input if we need to provide info about "upgrades install in the background" (so that people know if/why there machine is slow): DONE
add support to clasify some packages as "not safe for in-place-upgrade" (like firefox). u-n honors XB-Upgrade-Requires: {app-restart, session-restart, system-restart} : DONE
investigate set QoS rule for downloading of updates: POSTPONED
google would like an admin policy that prevents people disabling unattended upgrades (policykit tweaks?): POSTPONED
add unattended-upgrades pre and post scripts (or .d directories) support: TODO
be careful not to download or upgrade on battery, on mobile broadband connections, when in the middle of making a presentation: TODO
add support in session stop/shutdown to detect running upgrades (shutdown already implemented, but on system not session level): POSTPONED

mpt 2011-06-11: I've updated the software updates specification to cover completing an update installation during shutdown/restart. <> We still need to work on the design of background updates vs. battery and mobile broadband. However, I do not think we should add more interface elements for turning on background installation, when there is an existing interface for that which has been confusingly broken for five Ubuntu releases now (bug 351484). For all we know, fixing the existing interface might solve the "people are annoyed" problem entirely; and conversely, adding more interface might confuse enough people that Ubuntu installations end up *less* up-to-date on average. So, let's (1) fix the existing interface, (2) do the other work described here, (3) start measuring the distribution of how long ago Ubuntu machines were last updated (like <>), and (4) use that data to decide how to change the interface in future.

Experimental design:


For releated UI work:

Notes from Oneiric planning:
- Make it easy to enable unattended-upgrades via e.g. a additional button in update-manager. When that is pressed it should turn on unattended-upgrades in the "minimal-chunks" mode so that on e.g. shutdown the delay is as minimal as possible without breaking anything.
- apt-get --download-only for daily jobs?

Notes from the session:
Unattended upgrades: people are annoyed at the moment because it seems like when they log in there are always updates; don't want updates to block shutdown either; some packages (like firefox) can't be shut down in the background.

Could have an option in the update manager to do it in the background from now on.

Dialog at the moment is more complicated than mpt would like (shock!); like that it has a settings button; that goes to the Software Sources configuration panel. A checkbox would be more obvious, but could be clicked by mistake etc.

People may wonder why their computer is running slow; might also need to warn about wired broadband etc;

Issues about blocking shutdown. Does block session shutdown. Shows a series of "please wait" notifications.

need to consider entirely unattended upgrades, where people cannot tell the machine it's ever ok to upgrade; also perhaps it should be on by default

cron-apt recommends against doing things by default; if the upgrade fails it's a big mess

perhaps should classify packages by "safe to upgrade" or not; this could also handle the firefox "not safe to live upgrade" case. also flags about the type of change: reboot required, urgency (eg emergency changes that should be installed even over 3g);

having many settings makes it more likely people will set it the wrong way; probably want some hidden settings

perhaps should start minimized to show the updates

separate downloads from actual installing

flag updates that will need reboots before installing them

log out before starting to install updates, so you can safely leave the machine alone

oracle java runtime puts the minor version number into the directory so that a live upgrade breaks running applications

set QoS rule for downloading of updates

try profiling maintainer scripts and make them faster

(Lotus Notes takes 15m to upgrade)

some update things may not need to be done synchronously

delta-debs that directly apply to the filesystem?
 - we have a separate session for delta upgrades:

profile running one whole upgrade and feed that into bootchart. (evan: dx might have done something similar already?)

google would like an admin policy that prevents people disabling unattended upgrades

pre and post scripts (or .d directories)

be careful not to download or upgrade on battery, on mobile broadband connections, when in the middle of making a presentation

aim for user-readable explanations of _why_ the change is needed in package changelogs

ideally they would be i18nzd

config file where you can say if you want to reboot automatically; off by default; cannot detect whether the machine is in use

somewhat messy plymouth screen while installing upgrades during shutdown

perhaps only actually mention updates if there's an important fix motivating running

Use aptdaemon for the actual install/upgrade (and potentially show UI to stop/cancel, check
with mpt)

Add information about "reboot-required", "app-restart-required".

Add support in session stop/shutdown to detect running upgrades.

Granularity of unattended-upgrades is it the same for security, updates, proposed, ppas?

actions / work items:
* UI work on making it easier to enable
 * show progress if an update is still running when you shut down
 * unattended downloads
 * inhibit reboot while upgrading packages


Work Items