Integration of NotAutomatic Backports into Update/Upgrade U/I
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
- Started by
- Completed by
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:/
https:/
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/
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/
Yes - NotAutomatic: yes, ButAutomaticUpg
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.