Owner

Current status

The necessary systemd infrastructure has landed in rawhide with the systemd 183 release.
The plymouth, PackageKit and GNOME pieces are all upstream but have not had upstream releases with the new strings/code yet. PackageKit is expected to release in two weeks, plymouth this week. GNOME will of course next release tarballs on the GNOME release schedule for 3.5.x. The feature is expected to be testable on real F18 systems in early July.

Detailed Description

By "offline" OS updates we mean package installations and updates that are run with the system booted into a special system update mode, in order to avoid problems related to conflicts of libraries and services that are currently running with those on disk.

Updates will be downloaded in the background, and the user will be informed about available updates only once they are actually ready to be installed.

Installing updates will still be the users choice - if system updates are available, we will offer 'Restart and install updates' in addition
to a plain 'Restart' in the menus.

Note that this feature does not prevent you from using yum and other commandline tools to install updates whenever you want to. We also differentiate updates of 'OS components' (which we want to do in this offline fashion) from application updates and installations, which should still
be possible from the UI without restarting the system.

The differentiation between 'OS components' and applications is necessarily a heuristic, since Fedora only knows about packages. The initial heuristic
is that a package is considered an application if it installs a desktop file that is shown in the menus. This is not perfect and can be refined when
additional metadata becomes available.

Also note that this feature is about implementing offline updates for GNOME. Other spins are not affected, although they could choose to use the same systemd and PackageKit infrastructure, and provide a similar experience.

Benefit to Fedora

Replacing libraries and files while the OS is running can cause problems ranging from application crashes to inconsistent system states where processes are using different versions of a library at the same time. By installing system updates 'outside' the normal system operation, we avoid these problems.

Secondary benefits of the work done for this feature include that we are downloading all updates before we notify the user about available updates,
and thus avoid unpleasant wait times.

Scope

Update systemd to version >= 183 (done in rawhide)

Complete the PackageKit support for offline updates (mostly done upstream)

Update gnome-packagekit to support offline updates

Update gnome-shell to offer 'Install updates and restart' when updates are available (GNOME bug #677394)

Adjust plymouth to show useful information during the offline update (done upstream)

How To Test

Testcase: Available system updates

Use repositories which have system updates available

Verify that you are not notified about available updates before they have been downloaded

The 'Software Updates' UI should not offer to directly install system updates

The user status menu should have a 'Restart and install updates' item

Testcase 2: Installing system updates

In the situation of testcase 1, choose 'Restart and install updates'

Verify that the system shuts down, then restarts in the system update mode

Plymouth should show a spinner or progress bar and inform you that software updates are installed

When this completes, the system should reboot again, bringing you to the login screen

Log in

Verify that the 'Restart and install updates' menuitem is gone

Rebooting the system now will not enter the system update mode, but just reboot as usual

Testcase: Update problem

Same situation as testcase 1, but with a package set that will not successfully update (one way to achieve this would be to manually set up a repository with an inconsistent set of updates)

Repeat the same steps as in testcase 2

Verify that the system update fails, but you get rebooted again and end up at the login screen again

Verify that you get notified about the failed update attempt

Verify that the failed system update is not tried again if you reboot again

Testcase: Commandline use

Same situation as testcase 1

Open a terminal and run yum update

Verify that this works as before

Testcase: Application updates

Use repositories which have application updates available

Open 'Software Updates'

Verify that the available updates are listed, and that you can install them without rebooting

Testcase: Non-privileged user

Create a user account

Set up PolicyKit policy so that this user is not allowed to install updates (TODO: details needed)

Verify that available updates do not cause notifications or other disruptions for this user