Integration of NotAutomatic Backports into Update/Upgrade U/I

Registered by Scott Kitterman on 2011-04-29

In Natty we changed backports to be a "NotAutomatic" repository so users have to explicitly install from backports to pull from there. This makes backports safer to enable, but it also means that there are potentially multiple new versions of a package available (e.g. something in -security or -updates and a new feature release in -backports). We should show this to users in a friendly way.

Blueprint information

Status:
Not started
Approver:
Steve Langasek
Priority:
Undefined
Drafter:
Scott Kitterman
Direction:
Needs approval
Assignee:
None
Definition:
Discussion
Series goal:
Accepted for oneiric
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

WORK ITEMS:
[mpt] design how multiple version should be presented in software-center and/or update-manager (they may have different descriptions and screenshots): DONE
[mvo] implement this presentation: POSTPONED
[echidnaman] Handle KDE things: POSTPONED
[mvo] CLI backports availability tool: POSTPONED

Design specification:
https://wiki.ubuntu.com/SoftwareCenter#updates
https://wiki.ubuntu.com/SoftwareUpdates#optional

Full Session notes:
Welcome to Ubuntu Developer Summit!
#uds-o #foundations #backports-ui
put your session notes here

In Natty we changed backports to be a "NotAutomatic" repository so users have to explicitly install from backports to pull from there. This makes backports safer to enable, but it also means that there are potentially multiple new versions of a package available (e.g. something in -security or -updates and a new feature release in -backports). We should show this to users in a friendly way.
Note from the SRU process discussion: Would like to make -proposed NotAutomatic and enable by default as well, so that should be considered in this work as well.
Background: changed how backports and apt work
Packages aren't taken from -backports unless explicitly requested
Means enabling -backports by default is safe (so we're going to do that)
New problem: when you're installing/upgrading a package, might be more than one candidate version (i.e. you could either take the -updates package or the -backports package)
How do we present this choice to users, and make sure they're aware of the implications.
Additionally, also going to set NotAutomatic on -proposed
Once you install a -backports/-proposed package, do you automatically get updates?
Yes - NotAutomatic: yes, ButAutomaticUpgrades: yes
What about kernel in particular? Always kernel packages in -proposed
 - Think has to do with the source for the current installed version (current kernel from -proposed -> update from -proposed)
How many people are using -proposed now? Don't know
-backports is on in a "large number" (bad backport from a few years ago caused a lot of noise)
3 UI challenges:
 1. How do we make -proposed look like "just a kind of thing, as opposed to something people turn on by accident"
 2. How do you sensibly present the ability to pick and choose the backports
 3. What happens if there's a backport and and update available simultaneously?
  3a. When new package is installed, want to present options for current or backport
Any user-friendly information on difference between normal, proposed, backports? changelog for proposed, nothing really for backports
Remaining issues:
 - Start at backported package, upgrade to release backport came from, but that release has a backport of a newer version, now have newer version, when the version you already were using is available
 - Do we need special rules for -proposed and the kernel?
What needs to change?
 - software-center
 - update-manager
 - Muon Suite (KDE)
 - synaptic? no
 - apt-get
   - also some CLI tool to show "what backports of currently installed software are available?"
Action Items:
[mpt] Create a Wiki page for design ideas
[echidnaman] Handle KDE things
[mvo] Implement things for u-s-c, u-m, CLI

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.