Différences entre versions de « Backports »
(→Documentation : englihs translation) |
(→Exemples : english translation) |
||
Ligne 186 : | Ligne 186 : | ||
* [http://familiasanchez.net/~roberto/howtos/debcustomize Debian Package Customization HOWTO]: a backports is a form of customization | * [http://familiasanchez.net/~roberto/howtos/debcustomize Debian Package Customization HOWTO]: a backports is a form of customization | ||
− | == | + | == Examples == |
− | + | Here are a few sample backports made by Cliss XXI: | |
* [[Backport par2]]: simple | * [[Backport par2]]: simple | ||
− | * [[Backport ettercap]]: simple | + | * [[Backport ettercap]]: simple as well |
− | * [[Backport Evince]]: | + | * [[Backport Evince]]: more complicated |
− | * [[Backport GCJ]]: | + | * [[Backport GCJ]]: in progress, would be useful for OOo2 Base |
− | |||
== Liens == | == Liens == | ||
* [[Compatibilité binaire]]: pourquoi les exécutables d'une distribution ne fonctionnent pas sur une autre? | * [[Compatibilité binaire]]: pourquoi les exécutables d'une distribution ne fonctionnent pas sur une autre? |
Version du 10 septembre 2006 à 00:01
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.
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)
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
- 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
:
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 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/ \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 -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) [2]. 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 unfortunately blindly 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, 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. 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:
gunzip par2cmdline_0.4-8.diff.gz gunzip par2cmdline_0.4-7bpo1.diff.gz interdiff par2cmdline_0.4-8.diff par2cmdline_0.4-7bpo1.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-7bpo1_i386.deb
Documentation
- A high-level HOWTO: A Heuristic-based Process for Backporting Debs
- Slides (in German :/) from backports.org founder. Even if you don't grasp German, have a look at the mentioned commands.
- 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: this tool might ease backports. To dig out.
- Debian Package Customization HOWTO: a backports is a form of customization
Examples
Here are a few sample backports made by Cliss XXI:
- Backport par2: simple
- Backport ettercap: simple as well
- Backport Evince: more complicated
- Backport GCJ: in progress, would be useful for OOo2 Base
Liens
- Compatibilité binaire: pourquoi les exécutables d'une distribution ne fonctionnent pas sur une autre?