What are Backports

Ubuntu releases a new version of its OS every 6 months. After a release, the version of all packages stays constant for the entire 6 months. For example, if Ubuntu ships with OpenOffice.org 2.0.x, it will remain at OpenOffice.org 2.0.x for the entire 6-month release cycle, even if a later version gets released during this time. The Ubuntu team may apply important security fixes to 2.0.x, but any new features or non-security bugfixes will not be made available.

This is where Ubuntu Backports comes in. The Backports team believes that the best update policy is a mix of Ubuntu's security-only policy AND providing new versions of some programs. Candidates for version updates are primarily desktop applications, such as your web browser, word processor, IRC client, or IM client. These programs can be updated without replacing a large part of the operating system that would affect stability of the whole system.

Backports also include an extras repository that holds some packages not found in the official package collections. These include mainly legally-risky packages, including many multimedia formats that are patent protected and some freeware commercial programs such as Adobe Acrobat Reader or Sun's Java Runtime Environment/Development Kit, which are protected by a strict EULA.

As of June 2005, we are also an official Ubuntu project, so we are acknowledged by the developers.

Stability

Backports candidates are tested by several Backports developers before they are allowed to be placed in the repository. Backports packages are thus safer to use than the development distribution. At minimum the packages should be usable in a manner that the average Backports developer could test. However, given the nature of introducing newer versioned packages from a development distribution into a stable, released distribution, problems can arise. The most common side-effects would be a bug that escaped testing, or a new configuration file format (or other kind of incompatibility). If you have problems with a Backports package please report it in the [https://launchpad.net/products/feisty-backports/+filebug Backports bugtracker] and not the main Ubuntu one.

How to use

First make sure you have the Updates and Security [https://help.ubuntu.com/community/Repositories repositories] enabled (also available for [https://help.ubuntu.com/community/Repositories/Kubuntu Kubuntu]), as some packages from Backports rely on them. In addition, verify each repository has the "Main, Restricted, Universe, and Multiverse" components enabled. Backports will at times cross into a separate component in a manner that would be disallowed in other official repositories.

Installing a single package

A list of packages in Backports can be found at [http://packages.ubuntu.com/ the Ubuntu packages site] ([http://packages.ubuntu.com/feisty-backports/ Ubuntu 7.04], [http://packages.ubuntu.com/edgy-backports Ubuntu 6.10], and [http://packages.ubuntu.com/dapper-backports/ Ubuntu 6.06] backports).

Packages can be downloaded using your browser (choose the correct link for your system under the "Architecture" column)

Right-clicking on a downloaded package will offer an option to install the package. Downloaded packages can also be installed from a shell by typing

sudo dpkg -i ~/Desktop/<filename>.deb

(assuming the package was downloaded to the desktop).

After installing a package, it is advised to run

sudo apt-get -f update

in order to resolve any pending dependency issues.

Another method for installing a single package is to enable the whole repository, but use pinning so that it is only used when specifically requested -- see below.

Enabling the entire repository

Command Line Interface

Just add the following lines to your /etc/apt/sources.list :

For Ubuntu 7.04 (Feisty Fawn):BR deb http://archive.ubuntu.com/ubuntu feisty-backports main universe multiverse restricted

For Ubuntu 6.10 (Edgy Eft):BR deb http://archive.ubuntu.com/ubuntu edgy-backports main universe multiverse restricted

For Ubuntu 6.06 (Dapper Drake):BR deb http://archive.ubuntu.com/ubuntu dapper-backports main universe multiverse restricted

After refreshing the package manager's cache, packages from the backport repositories will now be available for installation.

Through Package Manager

Adept (Kubuntu)

Using the directions on the [https://help.ubuntu.com/community/Repositories/Kubuntu How To Add Repositories Page for Kubuntu], just activate the Unsupported updates in the Updates tab.

Synaptic (Ubuntu, Xubuntu)

Using the directions on the [https://help.ubuntu.com/community/Repositories/Ubuntu How To Add Repositories Page for Ubuntu]; and the following information for each section:

For Ubuntu 7.04 (Feisty Fawn): {{{url: http://archive.ubuntu.com/ubuntu distribution: feisty-backports sections: main universe multiverse restricted }}}

For Ubuntu 6.10 (Edgy Eft): {{{url: http://archive.ubuntu.com/ubuntu distribution: edgy-backports sections: main universe multiverse restricted }}}

For Ubuntu 6.06 (Dapper Drake): {{{url: http://archive.ubuntu.com/ubuntu distribution: dapper-backports sections: main universe multiverse restricted }}}

Use pinning to limit the backports repository

You may want to keep your system as close to the normal repositories as possible, and only use the backports when you have to. APT has a mechanism called pinning that will allow you to do this. Assuming you are using Ubuntu 7.04 (Feisty Fawn), save the following text in /etc/apt/preferences (note: this file might not already exist):

{{{Package: * Pin: release a=feisty-backports Pin-Priority: 400 }}}

This code will set the priority for the 'feisty-backports' archive to 400, which is lower than the default (500), so that apt-get will not automatically upgrade to packages in the backports repository. The line release a=feisty-backports selects packages that belong to the 'Archive' (or 'Suite') called 'feisty-backports'. If you are not using Ubuntu 7.04, look in /var/lib/apt/lists/*_Release to find the values to use in this line.

If you actually want to install packages from the backports, you will have to use the -t (target) option to apt-get. To upgrade a single package e.g. amarok, do this:

sudo apt-get install -t feisty-backports amarok

(Using -t is equivalent to setting a Pin-Priority of 990, so the priority for feisty-backports packages now beats that for the feisty, and the new version of amarok, with its dependencies, will be installed).

To see what is available in backports for upgrading, do:

sudo apt-get upgrade -u -t feisty-backports

Anchor(request-new-packages)

How to request new packages

When you need a package backported which is not currently available, create a new bug report in the Backports Product of Launchpad (for Ubuntu 6.06: [https://launchpad.net/products/dapper-backports/+filebug], for Ubuntu 6.10: [https://launchpad.net/products/edgy-backports/+filebug], for Ubuntu 7.04: [https://launchpad.net/products/feisty-backports/+filebug]). Choose a good summary that will quickly indicate the requested package needed (e.g. "Please backport Bittornado"). Indicate the current version of the package and version you would like. Please check to see if the requested version has entered Edgy (and Feisty), and let us know to make our lives easier!

These are the rules we try to follow when backporting packages:

1. Only packages currently in Ubuntu's development branches are eligible for backporting. We do NOT take packages from Debian repositories, unofficial repositories, or user-contributed source or binary packages.
2. Backports of large, interdepending application stacks are bad!
3. New versions can be backported when they are already compatible with OS and system-relevant libraries.
4. No new libraries that will "break" or affect other applications (e.g. libvorbis, libz, etc.) unless the update fixes an exploit.
5. No changes to language interpreters (python, mono). These could affect existing packages in unexpected ways.
6. Applications to be backported must have meaningful benefits to the user not attainable via other processes. Specifically:

   1. The sole purpose must not be to fix a bug or security vulnerability. There are more correct processes for these types of defects (specifically Security team and [https://wiki.ubuntu.com/StableReleaseUpdates]). Exceptions may be granted ONLY in the case that the other processes have failed or refused to address the issue. Please, for bugfixes, try [https://wiki.ubuntu.com/StableReleaseUpdates] first. We will reject any Backports requests for bugfixes if SRU has not been attempted.

   2. The application, therefore, should have some significant new feature or benefits.

How to Help

Backports is largely powered by users and volunteers. We would appreciate any and all community involvement, but ask that it be constructive towards the progress of Backports. Some suggestions include:

• Filing requests. We would not know what to do without your input

• Helping to sift through requests, looking for obviously invalid ones, such as ones listed above in the rules.

• Helping to build test packages, or feed package requests to [http://sharkattack.media.mit.edu/request Sharkattack]

• Helping to test built packages for proper functionality.
• Helping to raise community awareness and get others involved.

Backport Process

1. User files request as described above.
2. A test build of the backport is attempted. Possible ways include:
   • The pbuilder or Prevu build tool is used to generate testing .debs. Both are equally acceptable; Ubuntu developers would tend to have pbuilder already set up and ready to use, while most users would opt for Prevu's simpler setup routine and backporting convenience.

   • A new automated build system, called [http://sharkattack.media.mit.edu/ Sharkattack], is used to automatically generate testing debs. Sharkattack is easier to use, as it is a purely web-driven application. To request a backport, you simply have to fill out a form indicating what package you want, where you want to backport from/to, and an e-mail address to subscribe to build status. You can even paste in a Launchpad bug URL for the e-mail and it will send notifications directly to a bug ticket. Build logs are available, along with APT repositories containing binaries for i386 (if the build succeeds of course)

     • FYI: Sharkattack uses a slightly modified version of prevu, which will build packages in a very similar fashion to official build servers.

     • NOTE: Sharkattack is still beta-quality in development software, and as such it may not always be up or fast.

   • No other build methods will be accepted -- Please do not compile from source manually, use checkinstall, use dpkg-buildpackage, .debs from other websites, or any other testing method. It is of no use to our testing.

3. If a test build has succeeded, the bug ticket should be marked CONFIRMED and a comment should be added asking for testing feedback.

4. Users and backporters should try to install and run the built test packages (if none were provided, they should attempt a build themselves using the accepted methods.
   • This is a very important step. Several times before, I have caught packages that build correctly but either do not install, or crash upon running. Do not be hasty!

5. If the package runs well, please mark as TRIAGED

6. Users and backporters should continue testing, even when the bug is in a Triaged state.
7. Once Backporters are sufficiently satisfied with the testing coverage, the package will be marked for approval.

   • A backporter will mark the bug status as IN PROGRESS and subscribe team ubuntu-archive

8. Ubuntu Archive Admins will, in approximately one week, push out backports builds to all the mirrors. They will mark the bug FIX RELEASED

As far as changing the status on the bug tickets, we welcome users to set bugs to any of the above states as appropriate, except the "In Progress", "Fix Committed", and "Fix Released" states. These are limited to authorized backports or core developers.

Failure Modes

1. INCOMPLETE: A package requested is not currently in Ubuntu repositories but is expected to be in the future. Also packages that were abandoned during testing phase.

2. INVALID: A package requested is not available in Ubuntu repositories and not expected to be. Also, a package that failed any of the above testing stages.

3. WONTFIX: A valid backport that is too complex, requires source changes, has stale testing, or for some other reason Backporters are not willing to perform the request.

Useful Links

• [http://ubuntuforums.org/forumdisplay.php?f=47 Backports Forum]

• [http://lists.ubuntu.com/mailman/listinfo/ubuntu-backports Backports Mailing List]

• [http://ubuntuforums.org/showthread.php?t=153402 Forum post about creating a new backport request]

CategoryUbuntuTeams CategoryDocumentation CategoryCleanup