UpgradingRunningPrograms

Summary

While servers typically run services which can be restarted via init scripts upon upgrade, desktop software does not have that option. Many programs, in particular Firefox, do not behave well when an upgrade happens while the program is running. The current method of dealing with this is to pop up a notification, but this is a poor user experience if the upgrade occurred automatically and at a time inconvenient for the user. We suggest determining a method of deferring updates of running programs until the programs or the computer is restarted.

Release Note

From the end user perspective, the current behavior is that when they receive a Firefox (for example) upgrade, whether automatic, or performed manually, and Firefox is running, a pop-up tells them that a restart of Firefox is necessary. If they do not, Firefox behaves very poorly. The proposed behavior is that Firefox does not get instantly upgraded, but rather the user receives a notification that an update is available and they should restart firefox to have it installed. The notification should be nagging, similar to the update-notifier, the only difference being that it requires an application restart rather than just running the update.

Rationale

Upgrading packages in a way that breaks a currently running program is a very poor experience. It's not always easy for a user to correlate a poorly running program with a recent update. The current mechanism for upgrades doesn't make this easy, and the work-around is a pop-up notification telling the user to restart a program. This pop-up may be ignored, may not be displayed (update-notifier is often disabled in an enterprise environment), or may simply occur at a time which is very inconvenient for the user. This is more of a concern if upgrades are done automatically as is common in an enterprise environment because the user will be unaware that an upgrade is even occurring.

A better experience for the user is to notify them that an upgrade for a running program is available and that the update will be installed when the program or computer is restarted. A number of programs for other operating systems require that the program be shut down before upgrading.

User stories

Assumptions

Design

This could be done at a number of different layers. From fine-grained to large-scale:

Fix each package

Ideally, every package would upgrade without causing an interruption to its use.

Pros:

  • In an ideal world, all packages would be perfect.

Cons:

  • Not feasible to fix every package or maintain every future package to behave in this ideal manner.

Place problematic packages on hold and wrap the program in an upgrade script

This involves identifying the problematic packages and placing them on hold. The binary for the package is moved and replaced with a wrapper script which checks if an upgrade is available and either performs the upgrade or notifies the user that an update is available.

Pros:

  • Requires no modification to existing systems.

Cons:

  • Increases startup time for the application.
  • Involves package holds which aren't particularly common and difficult to enforce.
  • Involves new dependencies for each package that uses this method.

Perform something automatic at the package manager layer

It sounds like something like this is in the works for the ubuntu software center, which is good, but enterprise environments are unlikely to use the software center, and perform automatic updates directly on the system with apt-get or aptitude. Something could be done at this layer, or perhaps even lower, at the dpkg level. However, this level is likely where the job of re-performing the package at a later time will fall. For instance, the package could be installed when the program exits, when the program restarts, when the user logs out/in, or when the computer is restarted.

Add functionality to dpkg

This would need to be something configurable, similar to debconf, so upgrades could still be done non-interactively, and whether or not to install a disruptive package automatically should still be configurable, but one could imagine an interactive package install checking if the package would disrupt a running program, and if it would, provide the user with an option.

Pros:

  • Fixes the problem at a level that would work for any package, requiring less attention to the behavior of individual packages.

Cons:

  • Major change in the behavior of a major system.

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

Include:

  • data migration, if any
  • redirects from old URLs to new ones, if any
  • how users will be pointed to the new way of doing things, if necessary.

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.

CategorySpec

UpgradingRunningPrograms (last edited 2009-11-19 21:19:57 by 63)