UpdateManagerArchDependent

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.

Summary

The current release-upgrader is architecture independent. It only contains Python code. To be more flexible in the future we want to use selected arch-dependant code. This is useful to work around bugs in older versions or to use improvements required by the latest version.

Rationale

The current pure Python implementation makes it impossible to backport selected parts of the target distribution (e.g. dpkg, libapt). This means that for the dapper->edgy update the new breaks field could not be used because it was the dapper version of libapt that calculated the upgrade.

Use cases

  1. Ian implements a new dpkg field "Breaks" for edgy. The apt in dapper that will perform the dapper->edgy upgrade does not know about this field. With support for selected arch-any code it can learn about it and make deployment of new package management features quicker.

  2. The recovering from failing maintainer scripts is better in a recent version of dpkg. Fetching and using this version for a upgrade improves the user experience.

Scope

The ReleaseUpgrader needs to be modified to be able to fetch special .deb package to extend its functionality. Those .deb pacakges are similar to .udeb from the installer. A new pocket is added that stores those special packages.

Design

The release-upgrader is a python-apt application that is arch=all. It will be extended to download and install a special .deb package type to extend its functionality before doing the actual upgrade.

Those .deb packages will have a special prefix (e.g. releae-upgrader-$foo) and install into a hirarchy on the filesystem that does not overlap with the installed system (e.g. /usr/lib/release-upgrader). Maintainer scripts are discouraged and only allowed if the effects of those are fully reversible. Dependencies within the pocket are permited. The debs are stored in a special poket for the release (dist-uprader-$arch). That pocket contains a regular Packages file and is auto-build against the last distro release.

The release-upgrader will add this pocket to its sources.list and install any required pacakges before proceeding with the upgrade. It will resart itself if required (e.g. to get new libraries). When the user cancels the upgrade as part of its cleanup it will remove all packages it installed.

Implementation

No implementation work was done yet.

Old Design (for reference)

The old design has a matter of limitations. The most important one is that it does not support auto-building support for any arch=any components in the upgrader and that is uses a tgz as its container format and that does not contain any dependency information (this means that potential kde binaries need to be carried in the big tarball even if we are on a gnome system and vice-versa). The alternative approach is easier to implement and more flexible.

Scope

The upload handler in Launchpad needs to be modified to place arch=any packages into the right directory. Update-manager needs to be modified to support fetching the right package.

Design

The required steps are:

  • add new "UpgradeToolBaseURI" key to the meta-release file at http://changelogs.ubuntu.com/meta-release that contains the base-path to the upgrader

  • change DistUpgradeFetcher.py in update-manager--dapper to honor the new UpgradeToolBaseURI from the meta-release file and add "binary-$(dpkg --print-architecture)/current" to it

  • patch Soyuz to accept raw-dist-upgrade uploads that are not arch==all and move them to "$(dist)/dist-upgrader/binary-$arch/$version" (+ keeping a current symlink)

    • ColinWatson: My reading of the Soyuz code in question is that it already allows this; "all" isn't mentioned anywhere. Please double-check with the Soyuz team.

  • change the dist-upgrader to check/use the backports in the tarball
  • change the build system of the dist-upgrader to make sure to include the right backported binary bits
  • change the update-notifier dist-upgrader on cdrom detection to search for CDROM_ROOT/dists/stable/dist-upgrader/binary-$(arch)
  • change the CD build script (tools/$(dist)/upgrade.sh) to place the tarball into the CDROM_ROOT/dists/stable/dist-upgrader/binary-$(arch) subdir

Implementation

No implementation work was done yet.

CategorySpec

UpdateManagerArchDependent (last edited 2008-08-06 16:16:19 by localhost)