Backports

De Cliss XXI
Révision datée du 10 décembre 2007 à 12:22 par imported>SylvainBeucler (→‎Motives : link to binary compatibility description at autopackage.org)
Sauter à la navigation Sauter à la recherche

A backport is a Debian package that is recompiled for an earlier version of the distribution. For example, there is a backport from the latest version of KDE [1] that was compiled for Sarge, based on packages originally meant for Etch.

Français/French: Un backport, c'est un paquet Debian recompilé pour une version précédente de la distribution. Par exemple, il y a un backport de la dernière version de KDE [2] compilé pour Sarge, à partir des paquets initialement prévue pour Etch. Le reste de la page sera en anglais.

Motives

This recompilation is necessary for several reasons:

  • The packages dependencies change so as to take the evolution of the rest of the system into account; in our case, we'll change those dependencies to use earlier versions.
  • Binary compatibility issues (French: Compatibilité binaire, see also the Autopackage Packagers Guide section)

Where to find backports

backports.org is the reference.

There are also some repositories of lesser general purpose, but those do not necessarily check licences, so you might end up installed non-free components :/

With apt-get.org you can get a list of such repositories, either:

  • components not included in Debian for various reasons (patent threats, DMCA, etc.)
  • actual backports (newer versions recompiled for stable)

Using backports.org

Add the following line in your /etc/apt/sources.list: 

deb http://www.backports.org/debian sarge-backports main

Then install backported packages using: 

aptitude -t sarge-backports install BackportedPackage

(Before, you had to configure pinning (packages priorities), but this is no longer necessary)

Note: it is not recommended to install all backports at once. Instead you should select only the packages that you need. Unlike in full, consistent Debian distros, each backport is tested individually against the Debian stable version, so they might conflict with each others - but they still share common backported dependencies.

backports.org GPG key

After apt-get update, I get: 

W: GPG error: http://localhost sarge-backports Release: Les signatures suivantes
n'ont pas pu être vérifiées car la clé publique n'est pas disponible : NO_PUBKE Y EA8E8B2116BA136C

So I need to import that key from a keyserver: 

$ gpg --recv-keys EA8E8B2116BA136C
gpg: le porte-clés `/root/.gnupg/secring.gpg` a été créé
gpg: requête de la clé 16BA136C du serveur hkp subkeys.pgp.net
gpg: /root/.gnupg/trustdb.gpg: base de confiance créée
gpg: clé 16BA136C: clé publique « Backports.org Archive Key <ftp-master@backport s.org> » importée
gpg: aucune clé de confiance ultime n'a été trouvée
gpg:        Quantité totale traitée: 1
gpg:                       importée: 1

and tell apt about it: 

$ gpg --export EA8E8B2116BA136C | apt-key add -
OK

HOWTO backport?

Some general considerations:

Config

  • debootstrap
  • basic compilation tools: aptitude install build-essential
  • 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=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
  • Environment variables for Debian tools, in my ~/.bash_profile (TODO: not taken into account in my Sarge):
export DEBEMAIL="beuc@beuc.net" 
export DEBFULLNAME="Sylvain Beucler"
export EDITOR="emacs"
  • debsign GPG configuration, if signing packages is needed, in my ~/.devscripts:
DEBSIGN_KEYID="81704B93"
DEBSIGN_PROGRAM="gpg --use-agent"
DEBSIGN_SIGNLIKE="gpg"

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

apt-get build-dep packagename

will download the missing dependencies, if available, and report the first missing one otherwise.

You can alter the build-dep during the creation of the backport, to test whether a modified dependencies list does the trick. apt-get build-dep uses the plain-text /var/lib/apt/lists/ftp.[mirror].debian.org_debian_dists_[distro]_[component]_source_Sources file. 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). You then can test your backported dependencies with: 

apt-get -t sarge-backports build-dep packagename

You may also be interested in dpkg-checkbuilddeps: it reports packages that are not installed, though it doesn't tell you whether the build _could_ be installed or not, nor which packages exactly are missing.

Making the newly built dependencies available to apt

cd /usr/src
mkdir repo
\mv *-*~bpo.*.deb *-*~bpo.*.udeb *-*~bpo.*.changes *-*~bpo.*.diff.gz *-*~bpo.*.dsc repo/
ln -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

There's probably a cleaner way to do this using more comprehensive tools but that does the trick for now.

TODO: this doesn't support native packages (w/o .orig.tar.gz)

Don't's

Don't aptitude -t sarge-backports install debhelper blindly. This will include new helper scripts that may be copied into your packages' postinst/prerm/etc. This is being discussed. I had to stick to v4 when backporting evince.

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 for dpkg-buildpackage). Using debuild -us -uc directly worked well for me.

Upload

http://backports.org/contribute.html

Most commonly, upload your files (the contents of repo/) somewhere and post about it on backports-users@lists.backports.org. Make sure you included a description of what you did in the debian/changelog.

The page says: Our requirements aren't that high. You need to have a gpg key in the official Debian keyring. Don't get mistaken: only "Debian developpers" get their gpg keys in the keyring, and becoming one is a months-long process. However it is very easy to find somebody on the list who will upload your package.

Workflow

  • Your package hits testing. backports.org aims at providing a smooth transition between the current Debian stable release and the next one; they don't consider safe to use an unstable package because if may not enter the next stable (while a testing package should) [3]. Fortunately there has been some exceptions.
  • 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 (who will sponsor it), or you upload directly at ftp://backports.org if you have the privileges (requires being part of the Debian GPG keyring)
  • In any case, a binary package must be signed by a Debian developper. If your package is sponsored, it will probably be rebuilt. This rule is strictly enforced, even if you had your GPG key signed and have been around for months.
  • If this is the first time your package is backported (or if your source package introduces new binary packages), it will appear at http://www.backports.org/debian/new.html , and wait for a manual review. Norbert Tretkowski (nobse) or Alexander Wirt (formorer) will do so in a matter of days/weeks. eg: evince was accepted after 1 week, ettercap after 1 day - but I don't know the details.
  • An autobuilder builds your package for other architectures if available.

Test your backport

First, install and run your backport on a Stable system.

You can also check what changes you introduced using interdiff (from package patchutils): 

gunzip par2cmdline_0.4-8.diff.gz
gunzip par2cmdline_0.4-8~bpo.1.diff.gz
interdiff par2cmdline_0.4-8.diff par2cmdline_0.4-8~bpo.1.diff | less

debdiff will also show you if you mistakenly introduced new files, and will wdiff debian/control (you need to install the wdiff package for that): 

aptitude download par2
debdiff par2_0.4-8_i386.deb par2_0.4-8~bpo.1_i386.deb

Run lintian and linda, two packages test-suites, on your package. If you get errors, check whether they already existed in the original package, or if you introduced them yourself: 

linda par2_0.4-8~bpo.1_i386.deb
linda par2_0.4-8_i386.deb
lintian par2_0.4-8~bpo.1_i386.deb
lintian par2_0.4-8_i386.deb

(if your source packages produces several binary packages, specify the .changes instead)

piuparts is another test suite that actually installs your packages in various ways (instead of inspecting its content), but I have to figure out how to use it accurately for backports.

Track your backported packages

After a while, there will be new versions of your backported package in Debian testing. In this case, either:

  • update your backport
  • tell backports-users@list.backports.org that you do not intend to do it (lack of time, not using the package anymore, etc.), but that it would be good if someone did

To be notified of new versions of the package automatically, the simplest way is to subscribe to the PTS (package tracking system). You can do so from the package developer package (eg. [4]).

Alternatively, you can send an e-mail to pts@qa.debian.org telling: 

Subject: subscribe your_package your@mail.tld

keyword your_package your@mail.tld = upload-source
quit

The keyword line tells the BTS to only notify you about new releases. You can check the documentation to see what other kinds of notification you can receive (bug reports, etc.).


This script was recently advertised as a way to track the differences between Ubuntu and Debian packages.

MultiDistroTools also contains informations in this regard, generating reports like:

Such tools should be adaptable for use with backports<->testing.


Examples

Here are a few sample backports made by Cliss XXI:

Links

Documentation

Tools

Packages information

Other pages at doc.cliss21.org

(French):

Note

I put this documentation here because I'd rather publish it in a wiki where subscription or moderation is not required. Feel free to spread it though :)

There might still be some bits of French left on this page, from the early version of the document. Feel free to translate those.

As the only copyright holder of this documentation, and to avoid any troll, this documentation is dual-licensed GFDL and GNU GPL, current versions or later.

TODO

There are new "rules" to take into accounts:

Récupérée de « https://doc.cliss21.com/index.php?title=Backports&oldid=1502 »