UbuntuWiki:UpdateManagerEdgy

{{#ifexist: :UbuntuWiki:UpdateManagerEdgy/zh | | {{#ifexist: UbuntuWiki:UpdateManagerEdgy/zh | | {{#ifeq: {{#titleparts:UbuntuWiki:UpdateManagerEdgy|1|-1|}} | zh | | }} }} }} {{#ifeq: {{#titleparts:UbuntuWiki:UpdateManagerEdgy|1|-1|}} | zh | | }}

• Launchpad Entry: https://launchpad.net/distros/ubuntu/+spec/update-manager-edgy
• Created: Date(2006-06-09T12:58:07Z) by MichaelVogt
• Contributors: MichaelVogt
• Packages affected: update-manager

Summary

The spec covers proposed user interface improvements for the update-manager in edgy. The most important improvment will be to make it easy to spot why a package needs updating.

The repository dialog improvement/redesign is located on its own page UpdateManagerEdgyRepo.

Rationale

We have many updates during a stable cycle and the user wants to know why what packages is updated.

Use cases

1. Alice wants to see at a glance if there are any security updates.
2. Bob Has some 3rd party repositories and likes to know which of his upgrades are from ubuntu and which are from random 3rd party sites.

Scope

UpdateManager should be able to give the user a better idea about the importance of the various available updates by checking the origin (-security, -update, -backports, -proposed, 3rd-party) or reading the urgency hint in the changelog (either by downloading the changelogs or by checking a meta-file).

Design

The updates should be grouped by "security updates", "regulat updates", "3rd party updates", "backports". This can be determined by reading the "candidateOrigin" and can be represented in a listview with seperators and special headers or with a treeview. We need to test what is a better representation on a real system. Most likely we will go with a flat list.

In additon to this the interface should be split into user/root-mode (like gnome-app-install).

It should not be possible to run two instances of update-manager. We will use dbus to communicate if there is a frontend already runing and send a dbus message to it to bring it to the front (making it a singleton in effect).

Update manager should detect if kernels are available that are probably no longer needed (see PurgeOldKernels for details). If this is the case it will tell the user about it and offer a option to run the FreeDiskSpaceWizard to do the actual cleanup.

Implementation

What needs to be implemented:

• The current package list in update-manager will be extended to provide the additonal information required for the "show origin" information.
• user/root mode needs to be added and the user-mode needs to call the backend with the users selections for the updates
• A dbus interface needs to be added that supports a "bringToForground" method, each new update-manager instance checks if that method can be called on the current bus
• The check for old kernels needs to be added and the appropriate action (a dialog to start the FreeDistSpaceWizard) needs to be added.

Mockups for the update list

Flat list with separators

[X] firefox (important)
[X] xterm (important)
------------------
[X] evolution
[X] blabla
------------------
[x] skype

Treeview

> Security updates
  [X] firefox 
  [X] xterm 

> Updates
  [X] evolution
  [X] blabla

> Third party updates
  [x] skype

Code

No code has been written to implement this yet.

Outstanding issues

If we port it to smart, we need to make sure that the current policy of "no removals on a upgrade" is matched as well. This can probably be done by writing a smart policy for the upgrade that weights removals very negatively (unless they are really replaces).

---