|
Size: 23325
Comment: suggest better summary, also use lucid as example for versioning instead of dapper (obsoleted by now)
|
Size: 6549
Comment: Rewrite focusing on end-user processes
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 4: | Line 4: |
| 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 Open``Office.org 2.0.x, it will remain at Open``Office.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. | |
| Line 6: | Line 5: |
| 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. | When Ubuntu releases a new version of its OS every 6 months, that release is largely frozen in time. While the software that is part of that release will get bug fixes and security patches, new major releases of software and the new features that come with them will not be available. |
| Line 8: | Line 7: |
| Backports is an official Ubuntu repository and maintained by knowledgeable Ubuntu developers who are often present on IRC and other communications media. But note that software in backports will not receive review or updates from the Ubuntu security team itself. |
That’s where Ubuntu Backports comes in. Backports offers a way to selectively provide newer versions of software for older Ubuntu releases. Most commonly, the Backports team will provide new versions of standalone applications which can be safely updated without impacting the rest of the system. |
| Line 11: | Line 9: |
| = -backports vs -proposed/-updates/-security = A new user may be confused as to how the various official repositories that provides updates differ. |
== Security Support for Backports == |
| Line 14: | Line 11: |
| -'''Security''' offers patches for security vulnerabilities in Ubuntu packages. They are managed by the Ubuntu Security Team and are designed to change the behavior of the package as little as possible -- in fact, the minimum required to resolve the security problem. As a result, they tend to be very low-risk to apply and all users are urged to apply security updates. | Unlike the packages released with Ubuntu, Backports do not come with any security support guarantee. The Ubuntu Security Team does not update packages in Backports. When a package which has been backported receives a security update, the Ubuntu Backporters will make a best-effort attempt to update the backport. |
| Line 16: | Line 13: |
| -'''Updates''' offers patches for serious bugs in Ubuntu packaging that do not affect the security of the system. More directly, serious bugs are bugs that can directly cause loss of user data or represent a severe deviance from expected behavior. These updates are held up to similarly strict quality assurance as -security, in that the patches must be the minimum amount of change required to fix the bug. The fixes must be documented and verified by QA testers before they are accepted. These should also be low-risk to breakage and users are recommended to install them as a part of a regular update, or pick updates to bugs that affect them. | == Stability of Backports == |
| Line 18: | Line 15: |
| -'''Proposed''' is the testing area for -updates. A number of people must give positive feedback on these packages before they are allowed into -updates. This repository is recommended ONLY to people interested in helping to test updates and provide feedback. Since they are in effect testing updates, there is a higher chance of defective updates in this repository. | When using Backports, it is important to understand that there is an inherent risk in backporting software. Although backported packages are tested by the community before they are included in the repository, there are very occasionally bad interactions with the older software on your system that are overlooked. |
| Line 20: | Line 17: |
| Full up to date information on update policies can be found at [[https://wiki.ubuntu.com/StableReleaseUpdates|StableReleaseUpdates]]. The policies for main and universe differ, and can both be found at the mentioned page. | Additionally, the very nature of Backports means that backported packages will change the behavior of the package in ways that may be unfamiliar to users of the older versions, and may be incompatible with configuration format and other options of the older versions. |
| Line 22: | Line 19: |
| = Stability = Backports candidates are tested by several Backports developers and community contributors 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/lucid-backports/+filebug|Backports bugtracker]] and not the main Ubuntu one. |
For this reason, the Backports Team recommends configuring the package manager to only install backported packages when they are explicitly requested, which is the default for all Ubuntu releases after and including Ubuntu 11.04 (Natty Narwhal). |
| Line 25: | Line 21: |
| Due to the nature and purpose of Backports, it is not as "stable" as the previously mentioned update repositories, for a variety of reasons. | = Using Backports = |
| Line 27: | Line 23: |
| * Backports are designed to provide new features. These new features may be unfamiliar to users and require a period of re-learning to become familiar with their favorite application again. * Backports may introduce differing configuration file options or behavior that may catch an administrator off guard. For this reason it's not encouraged to upgrade backports as a part of an automated procedure on high-stability production environments. * Backports are newer software by definition, and newer software tends to be tested by fewer people. The risk for an uncaught bug is increased. |
There are two steps to configuring Ubuntu Backports; due to changes in Ubuntu, each step may or may not be necessary on a given release. |
| Line 31: | Line 25: |
| In assessing the "stability" of backports, it's important to define the term stability first. In terms of "the behavior I see today is the same as the behavior I'll see after applying a bunch of backports updates", Backports is fairly unstable. New apps introduced via backports may have significantly changed behavior or interfaces. In terms of "applying a backport will completely break my system", Backports is fairly stable. A great deal of work goes into testing backports and it's highly unlikely for a backport to be a severe regression from the version it replaces. | First, you must ensure that apt is configured with Backports enabled. On releases after and including Ubuntu 11.10 (Oneiric Ocelot), this is not necessary, as apt is configured with Backports enabled by default. |
| Line 33: | Line 27: |
| The user should judge for himself if Backports are appropriate for his purposes. | Second, you must determine whether apt should automatically install packages from Backports, or only install packages from Backports when they are manually requested. The Ubuntu Backporters Team recommends the latter option, and this was made the default for all releases after and including Ubuntu 11.04 (Natty Narwhal). The default for releases prior to Ubuntu 11.04 was to automatically install packages from Backports. |
| Line 35: | Line 29: |
| = How to use = | == Enabling Backports == |
| Line 37: | Line 31: |
| 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. | Backports were not enabled by default for all releases before (but not including) Ubuntu 11.10 (Oneiric Ocelot). On these releases, backports must be manually enabled before you can install packages from Backports. |
| Line 39: | Line 33: |
| == Installing a single package == | === Enabling Backports on Ubuntu Desktop === |
| Line 41: | Line 35: |
| A list of packages in Backports can be found at [[http://packages.ubuntu.com/|the Ubuntu packages site]] ([[http://packages.ubuntu.com/lucid-backports/|Ubuntu 10.04]] and [[http://packages.ubuntu.com/hardy-backports/|Ubuntu 8.04]] backports). | 1. Open the ''Software Sources'' control applet. On Ubuntu 10.10 and earlier, click ''System -> Administration -> Software Sources''. On Ubuntu 11.04 and later, search for Software Sources in the ''Dash''. 1. You will be asked to enter your password. Once you have done that, switch to the ''Updates'' tab. 1. Make sure ''Unsupported updates'' is checked. |
| Line 43: | Line 39: |
| Packages can be downloaded using your browser (choose the correct link for your system under the "Architecture" column) | === Enabling Backports on Kubuntu === |
| Line 45: | Line 41: |
| 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 | 1. Search for and start the ''Muon Package Manager'' in the ''KMenu''. 1. Once the ''Muon Package Manager'' opens, click ''Settings -> Configure Software Sources'' 1. You will be asked to enter your password. Once you have done that, switch to the ''Updates'' tab. 1. Make sure ''Unsupported updates'' is checked. === Enabling Backports Manually === Make sure the following line is in your `/etc/apt/sources.list` (substituting your release for `lucid`): |
| Line 47: | Line 51: |
| 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. You can use pinning to install packages from backports only 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 11.10 (Oneiric Ocelot):'''<<BR>> {{{deb http://archive.ubuntu.com/ubuntu oneiric-backports main universe multiverse restricted}}} '''For Ubuntu 11.04 (Natty Narwhal):'''<<BR>> {{{deb http://archive.ubuntu.com/ubuntu natty-backports main universe multiverse restricted}}} '''For Ubuntu 10.10 (Maverick Meerkat):'''<<BR>> {{{deb http://archive.ubuntu.com/ubuntu maverick-backports main universe multiverse restricted}}} '''For Ubuntu 10.04 (Lucid Lynx):'''<<BR>> {{{deb http://archive.ubuntu.com/ubuntu lucid-backports main universe multiverse restricted}}} '''For Ubuntu 8.04 (Hardy Heron):'''<<BR>> {{{deb http://archive.ubuntu.com/ubuntu hardy-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 11.10 (Oneiric Ocelot):''' {{{ url: http://archive.ubuntu.com/ubuntu distribution: oneiric-backports sections: main universe multiverse restricted |
deb http://archive.ubuntu.com/ubuntu lucid-backports main restricted universe multiverse |
| Line 99: | Line 54: |
| '''For Ubuntu 11.04 (Natty Narwhal):''' {{{ url: http://archive.ubuntu.com/ubuntu distribution: natty-backports sections: main universe multiverse restricted |
== When Backports Are Installed == Once Backports have been enabled, there are two primary configurations for when the Ubuntu package manager will install packages from Ubuntu Backports. You can configure apt either to always install packages from Ubuntu Backports, or you can configure apt to only install packages from Ubuntu Backports when they are explicitly requested. On releases before (but not including) Ubuntu 11.04 (Natty Narwhal), apt defaulted to always installing packages from Backports. On later releases, apt only installs packages from Backports when they are explicitly requested. Because of the potential for unexpected changes when upgrading to a backported package, the Ubuntu Backporters Team recommends configuring apt to only install backported packages on request. === Configuring Backports for Manual Install === Note: This is only necessary on Ubuntu releases before (but not including) Ubuntu 11.04 (Natty Narwhal); releases after and including Ubuntu 11.04 are configured in this mode by default. 1. As root, edit `/etc/apt/preferences`. You can do this by pressing Alt+F2, typing ''gksu gedit /etc/apt/preferences'' in the ''Dash'', and pressing Enter 1. Add the following text (substituting your release for `lucid`): {{{ Package: * Pin: release a=lucid-backports Pin-Priority: 100 |
| Line 106: | Line 72: |
| '''For Ubuntu 10.10 (Maverick Meerkat):''' {{{ url: http://archive.ubuntu.com/ubuntu distribution: maverick-backports sections: main universe multiverse restricted |
=== Configuring Backports for Automatic Install === Note: This is only necessary on releases after and including Ubuntu 11.04 (Natty Narwhal); releases before Ubuntu 11.04 are configured in this mode by default. 1. As root, edit `/etc/apt/preferences`. You can do this by pressing Alt+F2, typing ''gksu gedit /etc/apt/preferences'' in the Dash, and pressing Enter 1. Add the following text (substituting your release for `lucid`): {{{ Package: * Pin: release a=lucid-backports Pin-Priority: 500 |
| Line 113: | Line 82: |
| '''For Ubuntu 10.04 (Lucid Lynx):''' | = Installing Backports = If Backports are configured for automatic install, simply install packages as you normally would, using ''Ubuntu Software Center'', ''Muon'', `apt-get`, or any other tool. If Backports are configured for manual install, you must use the `apt-get` command-line tool with the `-t` option. For example, to install a single package, run: |
| Line 115: | Line 89: |
| url: http://archive.ubuntu.com/ubuntu distribution: lucid-backports sections: main universe multiverse restricted |
apt-get install -t lucid-backports amarok |
| Line 120: | Line 92: |
| '''For Ubuntu 8.04 (Hardy Heron):''' {{{ url: http://archive.ubuntu.com/ubuntu distribution: hardy-backports sections: main universe multiverse restricted }}} |
= Requesting New Backports = |
| Line 127: | Line 94: |
| == 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 10.04 (Lucid Lynx), save the following text in /etc/apt/preferences (note: this file might not already exist): {{{ Package: * Pin: release a=lucid-backports Pin-Priority: 400 }}} This code will set the priority for the 'lucid-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=lucid-backports'' selects packages that belong to the 'Archive' (or 'Suite') called 'lucid-backports'. If you are not using Ubuntu 10.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 lucid-backports amarok }}} (Using ''-t'' is equivalent to setting a Pin-Priority of 990, so the priority for ''lucid-backports'' packages now beats those of ''lucid'', and the new version of amarok, with its dependencies, will be installed). You can also choose a version number of a program to force apt-get to upgrade. You should note that because of the pinning, any dependencies that are required cannot be automatically upgraded in this case. However, if you use 'aptitude' instead of apt-get, its superior dependency handling will usually be able to offer the correct solution e.g.: {{{ sudo aptitude install koffice-kde4=1:2.0.0-0ubuntu1~jaunty1 }}} To see what is available in backports for upgrading, do: {{{ sudo apt-get upgrade -u -t lucid-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: * Ubuntu 8.04: https://launchpad.net/products/hardy-backports/+filebug * Ubuntu 10.04: https://launchpad.net/products/lucid-backports/+filebug * Ubuntu 10.10: https://launchpad.net/products/maverick-backports/+filebug * Ubuntu 11.04: https://launchpad.net/products/natty-backports/+filebug * Ubuntu 11.10: https://launchpad.net/products/oneiric-backports/+filebug Choose a good summary that will quickly indicate the requested package needed (e.g. "Please backport tmux 1.5-1 from oneiric to lucid"). Indicate the current version of the package and version you would like. Please check to see if the requested version has entered a later (or development) Ubuntu release, 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 repositories are eligible for backporting. We do NOT take packages from Debian repositories, unofficial repositories, user contributed sources, or REVU. 1. Backports should ideally build without any modifications from Ubuntu sources in a clean build environment 1. Namely, any source change requirements will significantly delay your request's processing time and hinder its acceptance 1. Backports should only affect themselves, and not cause any consequences to the rest of the system. 1. New versions of packages can be backported when they are already compatible with OS and system-relevant libraries. 1. A backport should never cause any other package on the system to break. Examples of this would be an incompatible library (see next item) or a commonly used command that changed its syntax. 1. New versions of libraries are strongly discouraged: 1. If the new version does not break its API and ABI, then it should be fine. 1. If there is an API/ABI breakage, but it only affects few (1 or 2) packages that can be fixed by rebuilding or backporting, an exception can be made. 1. No changes to language interpreters (python, mono, java). These tend to have a greater risk of regression that is extremely difficult to test for. 1. 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. 1. 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 the PPA. See the ''Backport Process'' section for details. * 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. 1. The request must be assessed against the rules defined above. Special considerations: 1. For libraries, determine if the API/ABI has changed by examining the changelogs or by more technical means. When in doubt, '''assume yes''' 1. To argue an incompatible library has minimal impact, attach a reverse dependency analysis (like apt-cache rdepends on each binary package name) and attempt rebuilding all those packages against the new library. 1. A test build of the backport is attempted. Possible ways include: * The pbuilder or [[https://wiki.ubuntu.com/Prevu|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. Other build methods typically used by Ubuntu developers are also acceptable (e.g. sbuild or cowbuilder). * A new, easier, procedure involving the Backports Tester Team PPA is in the works. Stay tuned for info. * '''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. 1. If a test build has succeeded, a comment should be added asking for testing feedback. 1. 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! 1. If the package runs well, please mark as '''''CONFIRMED''''' 1. Users and backporters should continue testing, even when the bug is in a Confirmed state. 1. 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''. * '''NEW POLICY''': All backport approval messages should explicitly mention the version of the package to backport. Remember that Archive Managers do not magically get spawned onto backport requests the moment they are approved, and if a newer version of a package is uploaded during this lag it could cause a serious compromise in Backports QA. 1. 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. 1. ''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. 1. ''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. = Technical Information for Ubuntu Developers = * A no-source-change backport is done by an archive adminstrator by a script once a [[https://launchpad.net/~ubuntu-backporters|backporter]] marks a ticket In Progress and subscribes ubuntu-archive. Only backporters should approve requests, please ping a backporter on IRC. * Backports are built against -backports -updates and -security, and are allowed to pull in dependencies from any components * If a backport outputs new binary packages, or is a new source package, it will be stuck in the queue. The queue will be cleared periodically and there is no need to poke anyone unless it is taking an unreasonable amount of time. To join the Backporters team, one must first be a MOTU or flavor developer (such as kubuntu-dev or xubuntu-dev). Everyone eligible is invited to join Backporters and are only required to be familiar with the rules and processes outlined in this document. == Source Change Backports == In addition to no-source-change backports, ubuntu-dev are allowed to upload directly to -backports for any package they have upload rights to (this includes per package upload rights uploaders). They will, however, require archive manager administrator. It is recommended, though not required, that a backporter independent of the person who prepares a source change backport double-checks source changes before uploading. That is, if you are a Backporter and prepare your own source change, it is recommended you get another backporter to review the changes before uploading it. === Requirements for Source Change Backports: === * Source Change backports are still subject to the general requirements for a backport. * Trivial/safe source changes are more likely to be reviewed and approved in a timely manner: * Build Dependency versioning may be relaxed as long as this doesn't introduce a regression. For example, "libfoo-dev (>= 0.5)" to "libfoo-dev (>= 0.2)" * Build Dependencies may be removed if preserving them require an inconvenient chain of dependencies. This also covers changing ./configure flags to turn off features that require newer dependencies. For example, brasero's backport from Hardy->Gutsy benefited from removing libbeagle-dev support. * Build dependency package names may be modified if they were renamed in development. For example, a package in Hardy depending on libfftw3-dev can be modified to depend on fftw3-dev in order to build on Gutsy. * Applying a minimally invasive patch to resolve an API change. For example, often times ffmpeg likes to rename API calls but otherwise not change functionality, so having a short patch that resolves this is acceptable. * Release must be set to ''target''-backports (lucid-backports, hardy-backports, and so on) * Uploads must follow the existing versioning policy. (Append `~${distro}1`, or if it is already there, increment the number. Examples: * 1.0-1 -> 1.0-1~lucid1 * 1.0ubuntu1 -> 1.0ubuntu1~lucid1 * 1ubuntu3~lucid1 -> 1ubuntu3~lucid2 * The changelog entry must document the changes made: * It must reference a Backports Launchpad bug number * It must also concisely list the source changes made. === Testing and Reviewing Process for Source Change Backports === The following procedure should be followed to streamline the testing and processing of source change backports. Each step could be done by a different contributor. * '''COMMENT''' on the backport request, make a coherent comment containing the following information: * What source changes were made? * Why were they made? Why was it safe to make? * '''ATTACH''' a debdiff that meets the above requirements. * '''KEEP''' bug status at New. * A backporter will review your proposal, and if it is accepted, it will continue to testing phase: * The backporter should upload accepted source changes into the [[https://launchpad.net/~ubuntu-backporters/+archive|Backports PPA]]. * Add '''~ppa1''' to the version number, in case multiple revisions are required. * Due to limitations of the PPA, the release will have to be changed back from (oneiric, natty, maverick, lucid)-backports to oneiric, natty, maverick, lucid, etc. * Set bug status to '''CONFIRMED''' once it is shown to build. * '''TEST''': The community should test the packages built from the PPA. A minimum of 3 "works for me" comments is required to pass this stage. * Once a backporter is satisfied with the testing phase, the bug status should be set to '''Fix Committed''' and package uploaded the package into the backports repository. * Once it is approved by an archive admin, set the bug status to '''Fix Released''' * '''REMOVE''' the test backport from the Backports PPA. = 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]] |
If you would like to request a new backport, please see our [[https://wiki.ubuntu.com/UbuntuBackports|documentation on the backport process]]. |
What are Backports
When Ubuntu releases a new version of its OS every 6 months, that release is largely frozen in time. While the software that is part of that release will get bug fixes and security patches, new major releases of software and the new features that come with them will not be available.
That’s where Ubuntu Backports comes in. Backports offers a way to selectively provide newer versions of software for older Ubuntu releases. Most commonly, the Backports team will provide new versions of standalone applications which can be safely updated without impacting the rest of the system.
Security Support for Backports
Unlike the packages released with Ubuntu, Backports do not come with any security support guarantee. The Ubuntu Security Team does not update packages in Backports. When a package which has been backported receives a security update, the Ubuntu Backporters will make a best-effort attempt to update the backport.
Stability of Backports
When using Backports, it is important to understand that there is an inherent risk in backporting software. Although backported packages are tested by the community before they are included in the repository, there are very occasionally bad interactions with the older software on your system that are overlooked.
Additionally, the very nature of Backports means that backported packages will change the behavior of the package in ways that may be unfamiliar to users of the older versions, and may be incompatible with configuration format and other options of the older versions.
For this reason, the Backports Team recommends configuring the package manager to only install backported packages when they are explicitly requested, which is the default for all Ubuntu releases after and including Ubuntu 11.04 (Natty Narwhal).
Using Backports
There are two steps to configuring Ubuntu Backports; due to changes in Ubuntu, each step may or may not be necessary on a given release.
First, you must ensure that apt is configured with Backports enabled. On releases after and including Ubuntu 11.10 (Oneiric Ocelot), this is not necessary, as apt is configured with Backports enabled by default.
Second, you must determine whether apt should automatically install packages from Backports, or only install packages from Backports when they are manually requested. The Ubuntu Backporters Team recommends the latter option, and this was made the default for all releases after and including Ubuntu 11.04 (Natty Narwhal). The default for releases prior to Ubuntu 11.04 was to automatically install packages from Backports.
Enabling Backports
Backports were not enabled by default for all releases before (but not including) Ubuntu 11.10 (Oneiric Ocelot). On these releases, backports must be manually enabled before you can install packages from Backports.
Enabling Backports on Ubuntu Desktop
Open the Software Sources control applet. On Ubuntu 10.10 and earlier, click System -> Administration -> Software Sources. On Ubuntu 11.04 and later, search for Software Sources in the Dash.
You will be asked to enter your password. Once you have done that, switch to the Updates tab.
Make sure Unsupported updates is checked.
Enabling Backports on Kubuntu
Search for and start the Muon Package Manager in the KMenu.
Once the Muon Package Manager opens, click Settings -> Configure Software Sources
You will be asked to enter your password. Once you have done that, switch to the Updates tab.
Make sure Unsupported updates is checked.
Enabling Backports Manually
Make sure the following line is in your /etc/apt/sources.list (substituting your release for lucid):
deb http://archive.ubuntu.com/ubuntu lucid-backports main restricted universe multiverse
When Backports Are Installed
Once Backports have been enabled, there are two primary configurations for when the Ubuntu package manager will install packages from Ubuntu Backports. You can configure apt either to always install packages from Ubuntu Backports, or you can configure apt to only install packages from Ubuntu Backports when they are explicitly requested.
On releases before (but not including) Ubuntu 11.04 (Natty Narwhal), apt defaulted to always installing packages from Backports. On later releases, apt only installs packages from Backports when they are explicitly requested.
Because of the potential for unexpected changes when upgrading to a backported package, the Ubuntu Backporters Team recommends configuring apt to only install backported packages on request.
Configuring Backports for Manual Install
Note: This is only necessary on Ubuntu releases before (but not including) Ubuntu 11.04 (Natty Narwhal); releases after and including Ubuntu 11.04 are configured in this mode by default.
As root, edit /etc/apt/preferences. You can do this by pressing Alt+F2, typing gksu gedit /etc/apt/preferences in the Dash, and pressing Enter
Add the following text (substituting your release for lucid):
Package: * Pin: release a=lucid-backports Pin-Priority: 100
Configuring Backports for Automatic Install
Note: This is only necessary on releases after and including Ubuntu 11.04 (Natty Narwhal); releases before Ubuntu 11.04 are configured in this mode by default.
As root, edit /etc/apt/preferences. You can do this by pressing Alt+F2, typing gksu gedit /etc/apt/preferences in the Dash, and pressing Enter
Add the following text (substituting your release for lucid):
Package: * Pin: release a=lucid-backports Pin-Priority: 500
Installing Backports
If Backports are configured for automatic install, simply install packages as you normally would, using Ubuntu Software Center, Muon, apt-get, or any other tool.
If Backports are configured for manual install, you must use the apt-get command-line tool with the -t option. For example, to install a single package, run:
apt-get install -t lucid-backports amarok
Requesting New Backports
If you would like to request a new backport, please see our documentation on the backport process.