Table of Contents
Ubuntu Backports Process
This page documents the development process for the Ubuntu Backports Project, as well as some of the justification for the project’s policies. If you’re not familiar with what backports are, or are trying to figure out how to install a package backported through the Backports Project, then our user documentation might be a good place to start.
Requesting a Backport
Backports must be approved by the Ubuntu Backporters team, but anybody can request a backport. As backports require testing before they can be approved, the backports team recommends that requesters of backports also test them when possible.
Backports are requested by filing a bug against the appropriate backports project, as listed here. The Ubuntu Backporters team recommends using the requestbackport tool in the ubuntu-dev-tools package to file backport requests. This tool is aware of many conventions for backports and can walk you through most of the verification steps.
During the initial evaluation, the backports team will evaluate the request against the following criteria:
Validity of the Backport
The Backports Project is a means to provide new features to users. Because of the inherent stability risks in backporting packages, users do not get backported packages without some explicit action on their part. This generally makes backports an inappropriate avenue for fixing bugs. If a package in an Ubuntu release has a bug, it should be fixed either through the Security Update or the Stable Release Update process, as appropriate.
This is the only requirement that requestbackport doesn’t help to check.
The Backports Project only backports packages from within the Ubuntu repositories. If a package is not yet available in the Ubuntu archive (perhaps because it is a new package, or because it has not yet been updated to the requested version), it is not a candidate for backporting.
When filing a backports request, please include in the Ubuntu release the backported package should be taken from, as well as the full Ubuntu version number of the package.
Source Packages Only
Because of the way that Ubuntu works, it is only possible to backport entire source packages, not individual binary packages. This means that, for instance, it would not be possible to backport only the openssh-server binary package; all packages built from the openssh source package must be backported. This can increase the amount of testing required for the subsequent steps.
Ensuring a Safe Upgrade Path
When a user upgrades from one Ubuntu release to the next, the version of any given package installed on his or her machine should be available in the Ubuntu release that user is running, assuming the package came from Ubuntu initially. In order to make this possible for backports which span multiple releases (e.g. a backport from Ubuntu 11.10 to Ubuntu 10.10), we may need to backport the package to the intervening releases (e.g. an additional backport to Ubuntu 11.04). These intervening backports will also require the same verification and testing.
Building a Backport
When a package is backported, it is rebuilt against the toolchain of the older release. Ideally the package should build without modification, though this is not always possible, and when it is not, some packaging knowledge may be required to adjust the packaging appropriately.
The backportpackage tool in ubuntu-dev-tools can simulate backports that do not require source modification, and test building them either using a PPA or a local builder (such as pbuilder or sbuild). The Ubuntu Backporters team prefers to see test backports done with backportpackage when source changes are not required.
In cases where a package does not build without source modifications, the required modifications should be attached to the backport request, in the form of a debdiff or a bzr branch. In order to keep the backported package close to the package being backported from, such changes should be as minimal as possible.
Testing a Backport
Once the package has been successfully built against the older release, it must be tested. The backports team generally relies on members of the community (and generally the requester of the backport) to do this testing.
After all required testing for a backport request has been completed but before a member of the backports team has approved the request, the status of the request should be set to Confirmed.
Functionality of the Backported Package
Each package being backported must install cleanly and without errors. The software in each package must also run. This may require some creative experimentation for packages such as libraries or modules which don’t ship any programs on their own.
Continued Functionality of Reverse-Dependencies
In addition to the backported package itself working, any other software that depends on the backported package must continue to run with the backported package installed, and any package that has a build-dependency on the backported package must build with the new package installed.
Approving a Backport
Before a backport can be approved, the request must contain the information outlined above. That is;
- Either a statement that the package builds unmodified on the older release or a statement that it does not together with a minimal diff which causes it to build.
- That the package installs correctly.
- That the software in the package runs.
- That any reverse-dependencies continue to function correctly after the new package is installed.
requestbackport ensures that your report contains all of the information needed for your backport request to be approved. It cannot, however, do all of the testing itself.
Backports must be approved by a member of the backports team. To approve a backport, the approving backporter uploads the package directly and sets the status of the bug to Fix Committed, adding a comment when they do so. The uploaded backport will then require manual acceptance by a member of the Ubuntu Archive Administrators team, so there may be a short delay at this point. If the backport does require source changes and the backports team has approved it, it will ordinarily be uploaded directly by the approving backporter, but can be uploaded via the same process as a normal Ubuntu archive upload, including going through the sponsorship process if necessary.