个人工具

UbuntuHelp:UbuntuBackports

来自Ubuntu中文

Wikibot讨论 | 贡献2009年11月17日 (二) 20:50的版本

(差异) ←上一版本 | 最后版本 (差异) | 下一版本→ (差异)
跳转至: 导航, 搜索


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 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. 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 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.

-backports vs -proposed/-updates/-security

A new user may be confused as to how the various official repositories that provides updates differ. -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. -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. -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. Full up to date information on update policies can be found at StableReleaseUpdates. The policies for main and universe differ, and can both be found at the mentioned page.

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 Backports bugtracker and not the main Ubuntu one. Due to the nature and purpose of Backports, it is not as "stable" as the previously mentioned update repositories, for a variety of reasons.

  • 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.

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. The user should judge for himself if Backports are appropriate for his purposes.

How to use

First make sure you have the Updates and Security repositories|enabled (also available for 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 the Ubuntu packages site (Ubuntu 9.10, Ubuntu 9.04, Ubuntu 8.10, Ubuntu 8.04 and 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 9.10 (Karmic Koala):<
> deb http://archive.ubuntu.com/ubuntu karmic-backports main universe multiverse restricted For Ubuntu 9.04 (Jaunty Jackalope):<
> deb http://archive.ubuntu.com/ubuntu jaunty-backports main universe multiverse restricted For Ubuntu 8.10 (Intrepid Ibex):<
> deb http://archive.ubuntu.com/ubuntu intrepid-backports main universe multiverse restricted For Ubuntu 8.04 (Hardy Heron):<
> deb http://archive.ubuntu.com/ubuntu hardy-backports main universe multiverse restricted For Ubuntu 6.06 (Dapper Drake):<
> 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 How|To Add Repositories Page for Kubuntu, just activate the Unsupported updates in the Updates tab.

Synaptic (Ubuntu, Xubuntu)

Using the directions on the How|To Add Repositories Page for Ubuntu; and the following information for each section: For Ubuntu 9.10 (Karmic Koala):

url: http://archive.ubuntu.com/ubuntu 
distribution: karmic-backports
sections: main universe multiverse restricted

For Ubuntu 9.04 (Jaunty Jackalope):

url: http://archive.ubuntu.com/ubuntu 
distribution: jaunty-backports
sections: main universe multiverse restricted

For Ubuntu 8.10 (Intrepid Ibex):

url: http://archive.ubuntu.com/ubuntu 
distribution: intrepid-backports
sections: main universe multiverse restricted

For Ubuntu 8.04 (Hardy Heron):

url: http://archive.ubuntu.com/ubuntu 
distribution: hardy-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 9.10 (Karmic Koala), save the following text in /etc/apt/preferences (note: this file might not already exist):

Package: *
Pin: release a=karmic-backports
Pin-Priority: 400

This code will set the priority for the 'karmic-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=karmic-backports selects packages that belong to the 'Archive' (or 'Suite') called 'karmic-backports'. If you are not using Ubuntu 9.10, 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 karmic-backports amarok

(Using -t is equivalent to setting a Pin-Priority of 990, so the priority for karmic-backports packages now beats those of karmic, 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 karmic-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:

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 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.
  2. 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
  3. 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.
    2. 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.
    3. New versions of libraries are strongly discouraged:
      1. If the new version does not break its API and ABI, then it should be fine.
      2. 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.
    4. No changes to language interpreters (python, mono, java). These tend to have a greater risk of regression that is extremely difficult to test for.
  4. 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 UbuntuWiki: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 UbuntuWiki: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 sit 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.
    2. 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
      2. 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.
    3. 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. 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.
    2. 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
    2. Users and backporters should continue testing, even when the bug is in a Confirmed state.
    3. 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.
    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.

    Technical Information for Ubuntu Developers

    • A no-source-change backport is done by an archive manager by a script once a backporter marks a ticket In Progress and subscribes ubuntu-archive. Only backporters should approve requests, though personally I (JohnDong) have no objections if a core-dev needs to backport something on an urgent basis. Otherwise, and for MOTU's, if you need a backport please either go through the formal process above or ping a backporter on IRC.
    • Backports are built against -backports -updates and -security, and are allowed to pull in dependencies from any of the "main restricted universe multiverse" 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. All MOTU's are invited to join Backports 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 Backporters (MOTU and core-dev as of Nov 2008) are allowed to upload directly to -backports. They will, however, require archive manager approval. As with before, I trust core-devs have the judgement to do this without Backporter intervention in case of emergency or backporter is not present. 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 benefits 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 (jaunty-backports, intrepid-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~dapper1
    • 1.0ubuntu1 -> 1.0ubuntu1~dapper1
    • 1ubuntu3~dapper1 -> 1ubuntu3~dapper2
    • 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 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 (jaunty, intrepid)-backports to jaunty, intrepid, 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