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.

For info about team rules and administration, see the team policies.

Responsibilities of the Backporter

You (or your sponsor) will need to prepare the backported package. This should be done with as few changes as possible to the backported package; any changes required should be explicitly stated in the changelog entry of the backported package.

Testing the Backport

You must test the backport in the Ubuntu release(s) you are requesting the backport for.

Functionality of the Backported Package

• Each package being backported must install cleanly and without errors.
• The software shipped in the package must also run.
  • You must detail your test process and results in the backport tracking bug.
  • In particular, make sure to run any build-time tests and autopkgtests **before** uploading.

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. In case that's not possible, the backported package must set appropriate package relations (Breaks, et al.) to prevent any incompatible installation (such Breaks could conceivably be part of the original package, it needs not be a backport-specific change).

Future Maintenance of the Backport

The Ubuntu Backports team is not responsible for the backported package.

The backporter is responsible for monitoring the backported package in the future for any bug reports, security patches, or additional updates that should be backported. Furthermore, the backporter is also responsible for any backport-specific bug that might be found in the backported package that wasn't present in the original version the backport was done from.

Procedure

Prepare and upload the package

The procedure is intentionally very similar to the existing SRU procedure, with minor changes specific to the purpose of the backports pocket. You should first read and understand that process, as this will page will only highlight the specific differences, and it assumes you are familiar with the SRU process.

Select the package to backport

Here are some nuiances of what to backport, from where and to where.

• There are some packages the Ubuntu Backports Team forbids from backporting.
• There are some packages the Ubuntu Backports Team handles themselves.
• Backports to non-LTS are not accepted (with exceptions).
• Backports are expected to come:
  • from the current Ubuntu stable release (preferred), or
  • from the current LTS release, targetting the prior LTS release, or
  • from the current package version in the current Ubuntu development release.

Currently decided exceptions to the above are documented at the bottom of this page, anything else needs to be discussed with the Ubuntu Backports team either in the tracking bug or in the mailing list.

Open a Bug

The first step is to open a bug in Launchpad for the backport. Open the bug against the package that you want backported, and include the prefix [BPO] in the bug subject. The bug description should include the BPO bug template, filled out with specific details for the requested backport. Make sure to subscribe the ~ubuntu-backporters team to the bug, so that we can track open requests that need the team's input.

Unlike the SRU process, which does not allow requesting a SRU to add features or functionality, the backport process does allow the need for new features or functionality. The backport bug does not need to list all fixed bugs or all the new functionalities but should highlight and/or summarize the key fixes or features or other reasons for needing to backport the package.

The bug's intention is to provide a location for any paperwork that might be required for the backport. For example, if any questions are raised during review or if any discussion is required, as well as providing a reference for anyone who might want to later see why and how a specific package was backported.

Preparing the Backported Package

As in the SRU process, you must prepare a package for the backport. Be sure to include the LP bug reference in the package changelog description; specifically, in the format "LP: #NNNNNN" (replacing NNNNNN with the number of the bug you opened for the backport).

If you have upload rights, you can then upload directly into the backports queue. Note that unlike uploading for SRU, when uploading into the backports queue, you should use the backports pocket; for example, in the changelog instead of using the release focal you should use focal-backports. Additionally, the version number you use should exactly match the version number you are backporting from, with a specific suffix added in the format ~bpoRELEASE.1, for example if backporting to release 20.04, append the suffix ~bpo20.04.1.

Version examples:

You must make sure that upgrades from the backported package to the next LTS+backports are covered.

This means that if you'd like to backport package X that is currently available in:

so that version 2.x.y is usable in bionic, you must first backport that version to focal, so that upgrades from bionic+backport to focal+backports are covered.

Finding a Sponsor

If you do not have upload rights you can request sponsorship in the same way as any other sponsored upload.

In the SRU process, a debdiff is preferred, however since the backport process typically will include a much larger change in code, you may want to propose a debdiff against the version you are backporting from instead of against the target release. Alternatively, you may want to simply link to a PPA where you have a backported build prepared; but it will be up to your sponsor to determine what format they would like you to provide the backported package for them to review and upload.

Review

These are some of the things the Backports Team will look at when reviewing your proposed backports.

Reason for Backport

Backports are intended to provide new features to older releases, and as such it is generally not acceptable to request a backport to only fix bugs that could be fixed using the normal SRU process. Any exception to this would need to be approved by the Ubuntu Backporters team on a case-by-case basis, with the backporter providing reasoning for why the bug should be fixed with a backport instead of using the SRU process.

One specific exception is the case of updating an existing backport; once a package has been approved for backporting, it may be updated for normal security patches and bug fixes that are added to the package in the later Ubuntu release where it is backported from. Future monitoring of the package is the responsibility of the backporter.

Another exception is any package that the backports team has already identified as eligible for backporting; a list of such packages is located at the bottom of this page.

Package Availability

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.

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. For backported packages, the policy is that users must be able to upgrade from LTS to LTS. We don't care about non-LTS for these considerations.

This also includes that when somebody backports something to the second-last LTS, it first needs to be made available in the last LTS.

Special Cases

What follows are some cases that have been discussed specifically, to which some of the above rules are waived.

Any addition to the section must first be discussed in the ML and agreed by the current team members.

Forbidden packages

Categories:

• any compilers (gcc, llvm, ...)
• any interpreter (python, ruby, php, ...)
• any core SSL libraries (openssl, nss, gnutls, ...) unless requested by Ubuntu Security Team

Source packages:

• linux*
• glibc
• xserver-*

Allowed in non-LTS releases

Core development packages

The following packages are allowed into the backports pockets of non-LTS releases, because they are deemed useful to always be available on the latest possible release. Care must be taken when preparing these releases as so to not break the upgrade path from one release to the other (this normally means uploading them to each suite from the newer to the older).

• debhelper
• devscripts
• pbuilder
• sbuild
• ubuntu-dev-tools

At the moment these 5 packages are handled by the Backport Team themselves.

Exceptions

In addition to the above core development packages, other packages can be granted an exception to allow backports in non-LTS releases, on a case-by-case basis. Please contact the team if you want to request a non-LTS backport exception for a package.

At this team meeting a non-LTS backport exception was granted to these packages:

• cockpit
• cockpit-machines
• cockpit-podman

BPO Bug Template

Bug title: [BPO] packagename/1.2.3.4-1 from releasename

[Impact] 

 * Justification for backporting the new version to the stable release.

[Scope]

 * List the Ubuntu release you will backport from, and the specific package version.

 * List the Ubuntu release(s) you will backport to.

[Other Info]
 
 * Anything else you think is useful to include

CategoryProcess