Summary

Users should only get applications (and required dependencies) from backports that they select and not all installed packages that have a backports candidate.

Release Note

The behavior of the backports section of 11.04 has changed from previous releases. Now, only packages you specifically ask to have updated from backports (and needed dependency updates). The means that if you choose to use backports, you can leave backports enabled to get updates of the packages you've decided you want from backports without having to worry about inadvertently getting packages you don't want too.

Rationale

This change is important for making backports safer for the average users to use. It also eliminates one comparative advantage the other package update services from outside the repository have had over Ubuntu Backports. If people are going to update past what we provide in the release, we would much rather they stay within the Ubuntu trust boundary to acquire newer packages.

This change resolves one long standing end user complaint about Ubuntu Backports.

User stories

Jane really needs a feature in the new version of Gimp and sees that it is available in lucid-backports. She enabled lucid-backports, selects gimp from backports, and updates it. She is pleased to see she isn't inundated with offers of lots of updates she neither needs not wants. She is a careful user and wants to stay with the supported packages in the release as much as she can.

John is well known for wanting the latest of every kind of crack on his machine. He opens update-manager, selects all the backports, and updates. He is happy.

Design

Set backports pockets to be "NotAutomatic" so that backports can be enabled and no packages are automatically installed. Enhance upgrade-manager (and kpackagekit) to allow backports packages to be separately displayed and selectable. Fix the apt resolver to be able to pull dependencies from a backports when needed.

Implementation

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.

BoF agenda and discussion

https://blueprints.launchpad.net/ubuntu/+spec/foundations-maverick-backports-notautomatic

Problem: we get a lot of backport requests in LTS, but enabling backports enables all of them.

Goal: To enable backports by default, but not install anything from it unless user indicates they want it. Dependencies would come when not met by regular archive.

Google did something similar with this internally. One problem is you need to be able to tell who deliberately upgraded to a backport and who was pushed their automatically. -- Google did it by setting pin priority for backports below normal (save an accident where pin was wrong and everyone got the backport)

Non-automatic flag in RELEASE file: leaves it unchecked by default in update manager. --problem: dependencies and the apt resolver --problem: current situation user learns what backports are as they enable them; having them clickable by default means we need to worry about explaining what they are within update manager

Some code in: lp:~mvo/update-manager/not-automatic (worth examining doing a change of the default release)

Need to fix apt resolver to pull depends from backports if they can't be satisfied from the release pocket (if the package requesting the dependencies is also from backports)

TODO:


CategorySpec

FoundationsTeam/Specs/BackportsNotAutomatic (last edited 2010-10-19 15:42:42 by kitterman)