Référence du développeur Debian
Chapitre 8 - Le portage

Debian supporte un nombre croissant d'architectures. Même si vous n'êtes pas un porteur et même si vous n'utilisez qu'une architecture, il est de votre responsabilité de développeur d'être attentif aux questions de portabilité. C'est pourquoi il est important que vous lisiez ce chapitre même si vous n'êtes pas un porteur.

Porter un paquet consiste à faire un paquet binaire pour une architecture différente de celle du paquet binaire fait par le responsable du paquet. C'est une activité remarquable et essentielle. En fait, les porteurs sont à l'origine de la plupart des compilations de paquet Debian. Pour un paquet binaire i386, par exemple, il faut compter une recompilation pour chaque autre architecture, soit un total de 12 recompilations.

8.1 Être gentil avec les porteurs

Les porteurs ont une tâche remarquable et difficile car ils doivent gérer un grand nombre de paquets. Idéalement, tout paquet source devrait compiler sans modification. Malheureusement, c'est rarement le cas. Cette section contient une liste d'erreurs commises régulièrement par les responsables Debian — problèmes courants qui bloquent souvent les porteurs et compliquent inutilement leur travail.

Ici, le mot d'ordre est de répondre rapidement aux rapports de bogues et remarques soulevées par les porteurs. Traitez-les courtoisement, comme s'ils étaient co-responsables de vos paquets (ce qu'ils sont d'une certaine manière). Merci pour votre indulgence envers des rapports de bogues succincts ou peu clairs ; faites de votre mieux pour éliminer le problème.

Les problèmes les plus couramment rencontrés par les porteurs sont causés par des erreurs de mise en paquet dans le paquet source. Voici une checklist de choses auxquelles vous devez être attentif :

1. Vérifiez que les champs Build-Depends et Build-Depends-Indep du fichier debian/control sont corrects. Le meilleur moyen pour vérifier cela est d'utiliser le paquet debootstrap pour créer un environnement unstable chrooté. Dans cet environnement chrooté il faudra installer le paquet build-essential et tous les paquets mentionnés dans les champs Build-Depends et Build-Depends-Indep. Ensuite, vous essayerez de fabriquer votre paquet dans cette environnement.

   Consultez le Debian Policy Manual pour en savoir plus sur les dépendances de fabrication.

2. Ne choisissez pas d'autre valeur que all ou any pour le champ architecture sans avoir de bonnes raisons pour le faire. Trop souvent, les développeurs ne respectent pas les instructions du Debian Policy Manual. Choisir la valeur « i386 » est la plupart du temps incorrect.

3. Vérifiez que votre paquet source est bon. Faites dpkg-source -x package.dsc pour vous assurer que le paquet se désarchive correctement. En utilisant le résultat de ce test, construisez votre paquet binaire à l'aide de la commande dpkg-buildpackage.

4. Vérifiez que les fichiers debian/files et debian/substvars ne sont pas dans votre paquet source. Ils doivent être effacés par la cible clean de debian/rules.

5. Assurez-vous que vous ne vous appuyez pas sur des éléments de configuration ou des logiciels installés ou modifiés localement. Par exemple, vous ne devriez jamais appeler des programmes du répertoire /usr/local/bin ou de répertoires équivalents. Essayez de ne pas vous appuyer sur des logiciels configurés de manière spéciale. Essayez de construire votre paquet sur une autre machine, même s'il s'agit de la même architecture.

6. Ne vous appuyez pas sur une installation préexistante de votre paquet (un sous-cas de la remarque précédente).

7. Si possible, ne vous appuyez pas sur une particularité présente dans un compilateur précis ou dans certaine version d'un compilateur. Si vous ne pouvez pas faire autrement, assurez-vous que les dépendances de fabrication reflètent bien cette restriction. Dans ce cas, vous cherchez sûrement les problèmes car quelques architectures pourraient choisir un compilateur différent.

8. Vérifiez que votre debian/rules distingue les cibles binary-arch et binary-indep comme l'exige le Debian packaging manual. Vérifiez que ces cibles sont indépendantes l'une de l'autre, c'est à dire qu'il n'est pas nécessaire d'invoquer l'une de ces cibles avant d'invoquer l'autre. Pour vérifier cela, essayez d'exécuter dpkg-buildpackage -b.

8.2 Instructions pour les mises à jour des porteurs

Si le paquet se construit tel quel sur l'architecture que vous visez, vous avez de la chance et votre travail est facile. Cette section s'applique dans ce cas ; elle décrit comment construire et installer correctement votre mise à jour indépendante binaire dans l'archive Debian. Si vous devez modifier le paquet pour le rendre compilable sur votre architecture cible vous devez faire une mise à jour des sources, consultez la section Comment faire une mise à jour indépendante source ?, Section 7.4.

Pour une mise à jour indépendante binaire, ne faites pas de changement dans les sources. Vous n'avez pas besoin de modifier les fichiers du paquet source (cela inclut debian/changelog).

La manière d'invoquer dpkg-buildpackage est la suivante : dpkg-buildpackage -B -eadresse-porteur. Bien sûr, remplacez adresse-porteur par votre adresse électronique. Cette commande construira les portions du paquet qui dépendent de l'architecture, en utilisant la cible binary-arch de debian/rules.

8.2.1 Numéro de version des mises à jour indépendantes binaires

Parfois il est nécessaire de recompiler des paquets quand d'autres paquets, tels que les bibliothèques, ont été mis à jour. Dans ce cas, vous devez changer le numéro de version pour que le système de comparaison des numéros de version fonctionne correctement. Ce type de mise à jour reste une mise à jour indépendante binaire — il n'est pas nécessaire de reconsidérer le statut des paquets binaires des autres architectures pour les marquer périmés ou à recompiler.

Ces recompilations nécessitent des numéros de version « magiques » pour que le système de maintenance de l'archive comprennent que, bien qu'il y ait une nouvelle version, il n'y a pas eu de modification des sources. Si vous ne faites pas cela correctement, les administrateurs de l'archive rejetteront votre mise à jour (car il n'y aura pas de code source associé).

Cette magie associée à une mise à jour par recompilation est déclenchée en utilisant un troisième nombre dans la partie debian du numéro de version. Si, par exemple, la dernière version du paquet que vous recompilez était « 2.9-3 », votre mise à jour portera le numéro « 2.9-3.0.1 ». Si cette version était « 3.4-2.1 » votre mise à jour portera le numéro « 3.4-2.1.1 ».

8.2.2 Quand faire une mise à jour indépendante source pour un portage ?

Les porteurs qui font des mises à jour indépendantes sources suivent généralement les instructions de la section Mise à jour indépendante, Chapitre 7 tout comme les non-porteurs. Les délais d'attente sont cependant plus courts car les porteurs doivent manipuler un grand nombre de paquets. À nouveau, la situation diffère selon la distribution visée.

Si vous êtes porteur et faites une mise à jour pour unstable, les instructions précédentes sont applicables à deux différences près. Tout d'abord, le temps d'attente raisonnable — délai entre le moment où vous envoyez un rapport au système de suivi des bogues et le moment où vous pouvez faire une mise à jour indépendante (NMU) — est de sept jours. Ce délai peut être raccourci si le problème est crucial et met l'effort de portage en difficulté : c'est à la discrétion de l'équipe de portage. (Souvenez-vous, il ne s'agit pas d'un règlement mais de recommandations communément acceptées).

Deuxième différence, les porteurs qui font des mises à jour indépendantes sources doivent choisir une gravité sérieuse (i.e. serious) ou supérieure quand ils envoient leur rapport au système de suivi des bogues. Ceci assure qu'un paquet source unique permet de produire un paquet binaire pour chaque architecture supportée au moment de la sortie de la distribution. Il est très important d'avoir un paquet source et un paquet binaire pour toutes les architectures pour être conforme à plusieurs licences.

Les porteurs doivent éviter d'implémenter des contournements pour des bogues de l'environnement de compilation, du noyau ou de la libc. Quelques fois ces contournements sont inévitables. Si vous devez faire quelque chose de ce genre, marquez proprement vos modifications avec des #ifdef et documentez votre contournement pour que l'on sache le retirer une fois que le problème aura disparu.

Les porteurs peuvent aussi avoir une adresse où ils publient le résultat de leur travail pendant le délai d'attente. Ainsi d'autres personnes peuvent bénéficier du travail du porteur même pendant ce délai. Bien sûr ces adresses n'ont rien d'officiel alors soyez sur vos gardes si vous les utilisez.

8.3 Outils pour les porteurs

Il y a plusieurs outils pour le travail de portage. Cette section contient une courte description de ces outils ; reportez-vous à la documentation de leurs paquets ou aux références citées ci-après pour une description complète.

8.3.1 quinn-diff

quinn-diff est utilisé pour localiser les différences d'une architecture à l'autre. Il pourrait vous dire, par exemple, quels paquets de l'architecture X doivent être portés sur l'architecture Y.

8.3.2 buildd

Le système buildd est un système distribué pour la compilation d'une distribution. Il est habituellement utilisé en conjonction avec des automates de compilation ; ce sont des machines « esclaves » qui récupèrent des paquets sources et tentent de les compiler. Il est aussi possible d'interagir par courrier électronique avec ce système. Cette interface est utilisée par les porteurs pour récupérer un paquet source (en général un paquet qui ne peut être compilé automatiquement) et travailler dessus.

buildd n'est pas disponible sous forme de paquet ; pourtant, la plupart des équipes de porteurs l'utilisent aujourd'hui ou ont prévu de l'utiliser bientôt. Il regroupe un ensemble de composants très utiles, continuellement utilisés mais non encore mis en paquet, tels que andrea, sbuild et wanna-build.

Une partie des informations produites par buildd — utiles pour les porteurs — est disponible sur la toile à l'adresse http://buildd.debian.org/. Ces informations incluent les résultats produits toutes les nuits par andrea (dépendances des sources) et quinn-diff (paquets à recompiler).

Nous sommes très enthousiasmés par ce système car il a de nombreux usages potentiels. Des groupes de développeurs indépendants peuvent utiliser ce système pour créer différentes saveurs de la Debian — qui peuvent être ou ne pas être intéressantes pour tous (une version de Debian compilée avec des vérifications relatives à gcc). Ce système nous permettra aussi de recompiler rapidement toute une distribution.

8.3.3 dpkg-cross

dpkg-cross est un outil qui installe les bibliothèques et les entêtes nécessaires à une compilation croisée[16] d'une manière similaire à dpkg. De plus dpkg-buildpackage et dpkg-shlibdeps ont été améliorés pour supporter les compilations croisées.

Référence du développeur Debian