Backports

Définition

Un backport, c'est un paquet Debian recompilé pour une distribution précédente. Par exemple, il y a un backport de la dernière version de KDE [1] compilé pour Sarge, à partir des paquets initialement prévue pour Etch.

Motivations

Cette recompilation est nécessaire pour plusieurs raisons:

• Les dépendences des paquets changent pour tenir compte de l'évolution de l'ensemble du système; ici, on changera ces dépendances pour revenir à des version antérieures.
• La compatibilité binaire est vraisemblablement inférieure sous GNU/Linux à celle de MS Woe: même en ignorant les dépendances, une différence de libc entre le système où l'on compile l'applicatino et le système où l'on l'exécute peut faire planter l'application. Il est donc nécessaire de recompiler, plutôt que de copier les binaires directement. Nous avons eu le problème en lançant le binaire testing de GNU Arch dans une Sarge (tous deux en version PPC). Cela me paraît un peu surprenant tout de même.

Où trouver des backports

backports.org est la référence en la matière.

Il y a également des dépôts de paquets plus spécialisés, mais ceux-ci ne sont pas toujours très attentifs aux licences, et vous pouvez récupérer des composants non-libres :/

apt-get.org fournit une liste de ces dépôts, à la fois ceux qui contiennent des composants non inclus dans Debian pour diverses raisons, et ceux qui fournissent des backports proprement dit.

HOWTO backport?

Some general considerations:

Config

• deboostrap
• sources.list:

##
# Stable and backports repositories
##
deb http://ftp.fr.debian.org/debian stable main
deb http://security.debian.org/debian-security stable/updates main
deb http://www.backports.org/debian/ sarge-backports main
deb-src http://ftp.fr.debian.org/debian stable main
deb-src http://security.debian.org/debian-security stable/updates main
deb-src http://backports.org/debian sarge-backports main

##
# Testing and unstable repositories
##

# Binaries - uncomment if you need to test 'aptitude install'
#deb http://ftp.fr.debian.org/debian testing main
#deb http://ftp.fr.debian.org/debian unstable main

# Sources - uncomment the one you're backporting from
#deb-src http://ftp.fr.debian.org/debian testing main
deb-src http://ftp.fr.debian.org/debian unstable main

##
# backports in progress
##
deb file:///usr/src/repo ./

• /etc/apt/preferences:

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

Package: *
Pin: release a=testing
Pin-Priority: -1

Package: *
Pin: release a=unstable
Pin-Priority: -1

• Vital packages (apt-src, apt-ftparchive, dch):

aptitude install apt-src apt-utils devscripts

To search for a missing dependency

In a vanilla install, sarge and backports in sources.list:

aptitude search keyword # search package whose name contain 'keyword'
apt-cache policy packagename # check what versions are available

Testing the build-deps

dpkg-checkbuilddeps.

Caution: it reports packages that are not installed, that doesn't tell you whether the build _could_ be installed or not.

Installing the build-dep

apt-get build-dep packagename

Altering the build-dep during the creation of the backport: apt-get build-dep uses /var/lib/apt/lists/ftp.[mirror].debian.org_debian_dists_[distro]_[component]_source_Sources.

You can go quick&dirty and alter that file. I do not know about a "clean" solution (like feeding apt-get build-dep directly with a debian/control file)

Making the newly built dependencies available to apt

cd /usr/src
mkdir repo
\mv *-*bpo*.deb *-*bpo*.changes *-*bpo*.diff.gz *-*bpo*.dsc repo/
\cp -f *.orig.tar.gz repo/
cd repo
apt-ftparchive packages . | gzip -c > Packages.gz
apt-ftparchive sources  . | gzip -c > Sources.gz
cd ..
#echo "deb file:///usr/src/repo ./" >> /etc/apt/sources.list

Don't's

Don't aptitude install debhelper/sarge-backports. This will include new helper scripts that may be copied into your packages' postinst/prerm/etc.

Don't use apt-src build, since it doesn't care about sources packages, unless you configure APT::Src::BuildCommand accordingly (without the -b option). Using dpkg-buildpackage -us -uc directly worked well for me.

Workflow

• Your package hits testing. Despite the homepage description, backports.org aims at providing a smooth transition between the current Debian stable release and the next one. Even if testing has an old version, backports.org won't host a later release [2]. Currently it is recommended to host a personal backport and reference it at apt-get.org - hopefully something better will come out.
• You backport the package.
• You test the package. It takes time to upload a package to backports.org, so you'd better send a perfect package from the start.
• You send the package to an authorized member, or you upload directly at ftp://backports.org if you have the privileges (requires being part of the Debian GPG keyring)
• If this is the first time your package is backported, it will appear at http://www.backports.org/debian/new.html , and wait for a manual review. Norbert Tretkowski (nobse) or Alexander Wirt (formover) will do so in a matter of days/weeks.

Documentation

• Un HOWTO: A Heuristic-based Process for Backporting Debs

• Des transparents (en allemand :/) du fondateur de backports.org. Même si vous ne connaissez pas la langue, notez le nom des commandes utilisées.

• Backports - Debian Wiki: some procedures to follow when uploading at backports.org. Policies are not explained, though.

• Package uploads: who uploaded what at bpo

• apt-build: cet outil pourrait servir à faciliter les backports. À creuser.

Exemples

Voici également deux exemples de backports réalisés par Cliss XXI:

• Backport par2: simple
• Backport ettercap: simple aussi
• Backport Evince: plus compliqué
• Backport GCJ: en cours, serait utile pour le module de base de données OOo2