UbuntuBackports
Backports are an important resource for many members of the Ubuntu community. That said, there are a number of problems that have arisen in the rest of the Ubuntu project due to the lack of connection and information exchange between the backports community and the core Ubuntu community. The entire Ubuntu community (including the backports guys and the "core" distro team) need to sit down, identify the problems, and then identify the best solutions.
The meeting produced a set of guidelines for Ubuntu Backports, which can be viewed here
Meeting
The Ubuntu Backports discussion meeting took place at June 1, 2005 at 1930UTC and will be held in #ubuntu-meeting.
Agenda
General Items
- General overview of the backports project. What it is and how it came to be.
The backports team should take center stage for a few minutes and put some information out to make the case for why backports exist and some of the value that they add to the Ubuntu community:
- Brief overview of demand for backports among users.
- Brief overview of potential usefulness of backports for developers.
The folks should helps put together a list of the limitations of backports and some of the problems that backports have caused so far. Items of this form raised so far include:
- Integration in the larger project issues:
- Backports users could be eager development release testers.
Backports maintainers could be in working on the new release.
- How is the upgradeability guaranteed, how many security updates receives a backports package and by whom?
- How are the tests for backport packages done to make sure they don't interfere with other packages or deinstall essential system basics by a wrong dependency?
- Backports fail to address a number of quality assurance issues:
- Who does the QA for the packages?
- Who reviews them and how many reviews does a backports package receive regularly?
- How can the backports team guarantee that system works after using their packages?
- Are backports rather using cdbs or debhelper?
- Communication issues:
- With whom of the distro team do backports maintainers communicate regularly about the changes their packages introduce?
- Other issues:
- What should we do with "bad" backports?
Proposals
Suggestions:
- Where is the middle ground?
- We should think about a Backport system like the Kubuntu Project.
- We don't do backports for an unreleased version.
- We don't do massive multi-level backports.
- We backport primarily from Ubuntu unreleased or Debian unstable - for desktop applications.
- We cut off all backporting when the new release is in Preview.
- We guarantee the Backport version number is ALWAYS less than the upcoming Release.
- We backport new versions when their compatible with the current OS and system-relevant libraries.
- We do not backport libraries.
- We have a special dev forum area where devs may contact us directly (we will need to know which devs would like to participate so that we may give them special access to this area) - also, we are looking to not only be more involved in the irc community discussions, but also integrating the forums and the irc channel(s) through forum plugins.
When to backport, when not to backport (suggestions up for discussion):
- Backports of large, interdepending applications stacks are bad!
- New versions can be backported, when they're compatible with already OS and System relevant libraries.
- No new libraries, which will "break" or better say, affecting other applications (e.g. libvorbis, libz etc.) until the update fixes an exploit (Brandon Hale suggests leaving these for the security team).
- No changes to language interpreters (python, mono). These could affect existing packages in unexpected ways.
- No Backports for packages in main!
- Applications to be backported must have meaningful bug/security fixes or features.
Current Backport packages
How to Use Ubuntu Backports Correctly
When to Use Ubuntu Backports
According to the individuals in the #ubuntu IRC channel on the Freenode IRC network, one should only uncomment the backports repositories in the /etc/apt/sources.list file when they face one of the following scenarios:
*looking for a package that isn't in the official/other repositories. *user absolutely MUST have the latest version of a particular package for some reason, and the latest version isn't available in the official repositories.
Example of How Ubuntu Backports can be Dangerous
I left the Ubuntu Backports repositories uncommented in my /etc/apt/sources.list and tried to use synaptic to install gaim-encryption. It was found in the backports repositories, but to install it, I would have to remove packages mozilla-firefox-gnome-support and ubuntu-desktop, both of which I want to keep.
I went into /etc/apt/sources.list and commented out the backports repositories, and reloaded synaptic package manager, and there was an official version of gaim-encryption that did NOT conflict with the mozilla-firefox-gnome support and ubuntu-desktop packages.
More on Backports
Here are the links you should read about backports:
To add the backports repositories, you'll need to read and understand how you add the backports repositories to /etc/apt/sources.list:
Don't Ever Trust Me
It is always possible that someone willing to lend a helping hand is wrong, so always double-check provided information using official sources. The following web pages allow you to search the official Ubuntu Wiki and Forum, respectively.