Ubuntu Wiki

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

• Launchpad Entry: https://blueprints.launchpad.net/ubuntu/+spec/upgrade-pre-requisites

• Packages affected: update-manager

Summary

Currently the release-upgrader is lacking a good way to download additional components that it requires to function. This is important to ensure that bugfixes for core components are available or to add functionality.

Release Notes

The upgrade-pre-requists feature is essential to perform long-term-release to long-term-release upgrades.

Rationale

New features get added to the package tools over time (e.g. the dpkg "Breaks" field). In order to perform a upgrade with those new fields, certain core components must be backported and fetched during the upgrade process.

Use Cases

Joe wants to upgrade from dapper to the next LTS release in ubuntu. Before this upgrade gets calculated, the release-upgrader downloads a updated version of libapt and dpkg so that the dpkg "breaks" field is fully supported. Now he can upgrade from one LTS to the next.

Scope

Update-manager needs to be modified to support fetching the pre-requists. Those need to be uploaded to soyuz and build against the old distribution.

Design

There are two types of pre-requisites:

1. regular fixes that go into $distro-updates that need to be installed before the upgrade

   • can be performed (e.g. a updated "konsole" package for the edgy->feisty kde upgrade)

2. backported core components like libapt/dpkg that are required to calculate/perform the upgrade and must be build against the version of ubuntu we upgrade from.

For type (1) we add a configuration option to the config file that allows specifying a package and a version (in the dpkg syntax). The upgrader will ensure that this version is installed before the upgrade is performed. It will look in "$distro-upgdates" and "$distro-security" for this. This behavior conflicts with the goal that a upgrade can be canceled and the system state is not changed. A exception for this is ok because updates in $distro-updates are tightly controlled via the SRU process and are recommended for all users.

For type (2) we will re-use the debian-installer infrastructure to build the backported packages against the "fromRelease". To do this, we use "debian-installer" as the section of the package and use priority "extra" or "optional" to avoid any confusion with the regular d-i. The upload target pocket is "$fromDistro-backoprts". The packages for the upgrader will be prefixed with "release-upgrader-$foo" (e.g. release-upgrader-apt) in the package name and the installs goes into a seperate directory (/usr/lib/release-upgrader) to avoid any conflict with installed applications. Debhelper (>= 4.2 is needed for this magic). The release-upgrader will only install the backport into its own temproary directory (using dpkg -x). A limitation of this infrastructure is that build-depends against $fromDistro-backports will not work. If that is needed, they need to be put into the source package.

Implementation

Type (1) pre-requists will be implemented in the release-upgrader in the "prepare()" step. There will be a new configuration option called "Depends: " that looks like a regular depends line. It can be both under the "View" section to describe global requirements and under a "DistUpgradeView$foo" section (e.g. DistUpgradeViewKDE) to describe requirements only needed when a certain view is in use.

For type (2) the release-upgrader will get a new configuration section called "PreRequists" that lists the packagenames that are required and the sources.list.d fragement. This fragment is added during the upgrade to sources.list.d and the requested packages will be downloaded and unpacked to the temporary directory that the release-upgrader is working in. Then PATH, LD_LIBRARY_PATH is modified and the upgrader re-execs itself (or re-imports apt_pkg) so that the new libraries get used.

A backported apt/python-apt package (both need to be in the same source package as build-depends are not possible) for dapper-backports will be prepared and uploaded. The debian-installer packages will be used as a example.

The package will be send to cprov before the actual upload so that it get tested on the dogfood launchpad test server.

Checklist

Follow this checklist to ensure that the package is properly build to be used as a pre-requist:

• prefix "release-upgrader" in the name in debian/control and debian/changelog
• build as udeb by adding "XC-Package-Type: udeb" to the debian/control file
• change section to "debian-installer"
• change changelog target to "$distro-backports"
• set priority to "extra"
• update package description to include message that this is *not* a real package
• either set the prefix to "/usr/lib/release-upgrader" *or* make the package conflict
  • with some important package (like dpkg) so that the user can never install it on a real system

CategorySpec