4 astuces pour maintenir un paquet Debian « 3.0 (quilt) » dans un système de suivi de versions (VCS)

La plupart des paquets Debian sont gérés grâce à un logiciel de gestion de versions (VCS – Version Control System) tel que git, subversion, bazaar ou mercurial. Les particularités du format « 3.0 (quilt) » ne sont pas sans conséquences sur la gestion des paquets dans un VCS, et cet article va vous présenter quelques astuces afin d’en rendre l’usage plus agréable.

(Tous les exemples présentés ci-dessous s’appuient sur l’utilisation de git comme VCS).

1. Exclusion du répertoire .pc

Le répertoire .pc est utilisé par quilt afin de stocker ses données internes (liste des patchs appliqués, sauvegarde des fichiers modifiés). Il est également créé par dpkg-source de telle sorte que quilt « sache » que les patchs sont situés dans debian/patches (et non dans patches, qui est le répertoire que quilt utilise par défaut). À ce titre, le répertoire est conservé même lorsque plus aucun patch n’est actuellemement appliqué.

Vous ne tenez cependant pas à conserver ce répertoire dans votre dépôt : il doit donc être mentionné dans la liste des fichiers exclus. Avec git, il suffit d’indiquer :

$ echo ".pc" >>.gitignore
$ git add .gitignore
$ git commit -m "Ignore quilt dir"

Le fichier .gitignore n’étant pas pris en compte par dpkg-source, le paquet source généré par ce dernier ne sera pas « pollué ».

2. Retirer les patchs après la compilation

Si vous stockez vos sources « amont » avec les patchs non appliqués (ce que font la plupart des gens) et que vous ne compilez pas vos paquets dans un répertoire temporaire prévu à cet effet, alors vous souhaitez probablement « désappliquer » les patchs après la compilation, de sorte à retrouver un dépôt dans un état « propre ».

C’est désormais le comportement par défaut de dpkg-source. S’il a dû appliquer les patchs, il les enlèvera automatiquement également.

Mais on peut tout de même forcer ce comportement en ajoutant « unapply-patches » à debian/source/local-options :

$ echo "unapply-patches" >>debian/source/local-options
$ git add debian/source/local-options
$ git commit -m "Unapply patches after build"

svn-buildpackage compilant systématiquement dans un répertoire temporaire, le dépôt est laissé exactement dans le même état qu’avant la compilation : cette option est inutile dans ce cas. Ce comportement peut également être demandé à git-buildpackage grâce à l’option --git-export-dir=../build-area/ (../build-area/ étant le répertoire utilisé par svn-buildpackage, cette option force git-buildpackage à se comporter comme svn-buildpackage).

3. Gérer vos patchs quilt comme une branche git

Plutôt que de gérer les patchs spécifiques à Debian via quilt, il est possible d’utiliser git lui-même. Avec git-buildpackage vient l’outil gbp-pq (Git-BuildPackage Patch Queue – File des patchs de git-buildpackage). gbp-pq permet l’export d’une série quilt dans une branche git, que vous pouvez alors manipuler comme vous le souhaitez. Chaque commit représentant un patch, vous devez « rebaser » cette branche afin d’éditer les commits intermédiaires. Jetez un oeil à la documentation de gbp-pq pour appronfondir le sujet.

Alternative à gbp-pq, l’utilisation de git-dpm est plus compliquée, mais présente l’avantage de conserver l’historique de toutes les branches utilisées pour générer les séries quilt de toutes les publications Debian. Son principe de fonctionnement est très bien expliqué sur son site, et vous pouvez également souhaiter lire la revue qu’en a fait Sam Hartman, qui en présente les limites.

4. Documenter la manière de passer en revue les modifications

L’un des principaux bénéfices liés à l’utilisation du nouveau format source tient au fait qu’il est dorénavant simple de passer en revue les modifications amont : celles-ci sont conservées en autant de patchs distincts proprement documentés (et, idéalement, en utilisant le format DEP-3). En utilisant les outils décrits précédemment, le message de commit devient l’en-tête du patch. Il devient donc important de saisir des messages de commit explicites.

Cette méthode fonctionne bien tant que votre méthode de travail prend appui sur les patchs Debian, regroupés dans une branche que vous rebasez sur les sources amont à chaque publication. Certains mainteneurs n’aiment pas cette méthode de travail et préfèrent voir appliquer les modifications propres à Debian directement sur la branche d’empaquetage. Ils sautent alors vers une nouvelle version amont en la fusionnant dans cette dernière. Il est difficile dans ce cas de générer une série quilt à partir du système de suivi de versions. Il faut à la place indiquer à dpkg-source de stocker toutes les modifications dans un seul patch (qui devient alors équivalent au bon vieux .diff.gz), et documenter dans son en-tête comment mieux passer en revue les modifications, par exemple dans l’interface Web du VCS.

Le premier comportement est obtenu en passant l’option --single-debian-patch, et le second en écrivant l’en-tête dans debian/source/patch-header :

$ echo "single-debian-patch" >> debian/source/local-options
$ cat >debian/source/patch-header <<END
This patch contains all the Debian-specific
changes mixed together. To review them
separately, please inspect the VCS history
at http://git.debian.org/?=collab-maint/foo.git
<Put more details here>
END

Ceci est une traduction de mon article 4 tips to maintain a “3.0 (quilt)” Debian source package in a VCS contribuée par Weierstrass01. Vous voulez d’autres tutoriels comme celui-ci ? Cliquez ici pour vous abonner à ma newsletter et recevoir les nouveaux articles par email.

Mes activités Debian en juillet 2011

Voici le récapitulatif mensuel de toutes mes activités gravitant autour de Debian. Si vous faites partie des personnes ayant fait un don pour soutenir mon travail (170 €, merci à tous !), c’est l’occasion de constater ce que je fais de votre argent. Sinon, c’est toujours quelques nouvelles intéressantes sur l’avancement de mes différents projets.

Le mois de juillet est passé à toute vitesse, en grande partie parce que j’ai participé à la fois aux RMLL – Rencontres Mondiales du Logiciel Libre et à la DebConf.

Les RMLL

Du fait de ma présence d’une semaine complète un peu plus tard dans le mois à la DebConf, je n’ai participé « que 3 jours » sur les 6 que duraient ces Rencontres.

Et, durant ces 3 jours, j’ai aidé à la tenue du stand Debian, déjà en de bonnes mains : celles de Frédéric Perrenot et Arnaud Gambonnet. Nous n’avions malheureusement aucun goodies à vendre, et c’est là un point sur lequel nous devrons nous améliorer d’ici la prochaine fois (par nous j’entends Debian France).

J’ai assisté, entre autres, à une conférence présentant EnVenteLibre. Ce site a été créé, au départ, comme boutique en ligne pour les associations Ubuntu-fr et Framasoft. Toute la logistique est sous-traitée, seules les commandes de goodies et leurs livraisons à l’entrepôt du sous-traitant sont de leur responsabilité. Ils peuvent également envoyer directement du matériel de l’entrepôt pour une conférence, par exemple. Nous avons discuté dans les grandes lignes d’une éventuelle adhésion de Debian France, voire même, pour Debian et toutes ses associations locales, de la possibilité d’opérer à l’échelle internationale.

Une fois de retour, et bien qu’ayant passé trois bonnes journées à Strasbourg, il m’a semblé que cet événement perdait, petit à petit, en importance : il est loin d’être de dimension internationale, et le nombre de conférences ne joue pas en faveur de la qualité.

En passant, est-ce que vous vous rappelez que Debconf 0 et Debconf 1 ont été associées à cet événement lorsqu’il s’est déroulé à Bordeaux ?

Améliorations de dpkg-source

J’ai apporté certaines modifications au format source 3.0 (quilt) durant mon séjour à Strasbourg (et plus particulièrement durant les trajets aller et retour !). dpkg-source refusera maintenant la compilation d’un paquet source si celui-ci comporte des changements upstream qui ne sont pas correctement enregistrés dans un patch quilt :

dpkg-source: info: local changes detected, the modified files are:
 2ping-1.1/README
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/2ping_1.1-1.diff.cki8YB

Comme le suggère le message d’erreur, une nouvelle option --commit supportée par dpkg-source permet de générer le patch quilt correspondant. Vous devrez, dans ce processus, soumettre un nom pour le patch généré et éditer son en-tête (pré-formaté avec des champs compatibles DEP3). Le retour à l’ancien comportement peut être forcé via l’option --auto-commit.

Changement des drapeaux de compilation

Depuis que dpkg-buildpackage définit lui-même les variables d’environnement relatives à la compilation (cf. n°465282, un changement proposé originellement par Ubuntu), de nombreuses voix au sein de Debian ont exprimé leurs insatisfaction quant à l’approche retenue. Ces commentaires mettaient en avant les problèmes créés sur certains paquets, et le fait que ces mêmes variables ne sont pas définies si l’on exécute debian/rules directement.

La modification fut toutefois conservée, et les paquets « cassés » par cette dernière ont été réparés. En dépit de tout ceci, décision fut prise plus tard de créer dpkg-buildflags comme l’interface appropriée pour injecter des drapeaux de compilation.

Avant de modifier dpkg-buildpackage de sorte qu’il ne définisse plus ces drapeaux, j’ai tenu à m’assurer que dpkg-buildflags soit suffisamment répandu (au sens d’utilisé) dans l’archive, afin d’éviter de casser de nouveau un trop grand nombre de paquets. J’ai retenu comme critère l’utilisation de dpkg-buildflags par CDBS et dh (de dhbhelper). La condition d’application fut satisfaite avec la modification récente de debhelper (cf. n°544844), j’ai donc modifié dpkg-buildpackage en conséquence.

Extraits (snippets) de makefile fournis par dpkg

En parallèle de ces travaux, j’ai souhaité mettre à disposition des mainteneurs une manière simple (qui n’utilise ni dh ni CDBS) de réparer les paquets impactés d’une part, et également d’injecter les drapeaux de compilation à partir des fichiers debian/rules. Ce sera possible à compter de la prochaine version de dpkg, via un bout de code ressemblant à ceci :

DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/default.mk

Sans DPKG_EXPORT_BUILDFLAGS à 1, les variables ne sont pas exportées dans l’environnement et sont sans effet, à moins bien sûr que vous ne les utilisiez autre part.

En plus de ces drapeaux de compilation, bien d’autres variables — pouvant être utiles dans les fichiers debian/rules — seront mises à disposition par ce biais : celles fournies par dpkg-architecture, les variables/macro liées à l’outil dpkg-vendor et quelques informations de base du paquet (principalement liées à la version).

Améliorations de dpkg-buildflags

Étant donné l’importance croissante que dpkg-buildflags va prendre maintenant que dpkg-buildpackage n’initialise plus les variables d’environnement correspondantes, j’ai pris le parti de corriger tous les bogues ouverts et d’implémenter quelques suggestions qui me sont parvenues.

J’ai également discuté avec quelques membres du comité technique de la manière dont les drapeaux de compilation renforcée (hardening build flags) pourraient être activés dans Debian. Discussion qui amena également certaines idées d’amélioration.

En résumé, voici les principales modifications réalisées :

  • Nouvelle directive « prepend » permettant d’injecter les drapeaux au début de la chaîne retournée (cf. ce commit);
  • Nouvelle directive « strip » permettant d’enlever des drapeaux de la sortie retournée par dpkg-buildflags (cf. ce commit);
  • Nouvelles variables d’environnement DEB_flag_MAINT_directive pouvant être initialisées par le mainteneur afin de paramétrer la sortie de dpkg-buildflags (cf. ce commit);
  • Nouvelle option --export=configure permettant d’injecter les drapeaux via la commande ./configure (cf. ce commit);
  • Nouvelle option --dump par défaut (cf. n°603435).

Tous ces changements rendent dpkg-buildflags capable de retourner l’ensemble des drapeaux de compilation possibles (il ne retournait auparavant que les drapeaux par défaut, et l’empaquetage Debian était supposé y ajouter tout élément supplémentaire nécessaire après coup). Le travail du mainteneur se réduit maintenant, pour cette partie, à utiliser les nouvelles variables d’environnement, afin de s’assurer que les valeurs retournées correspondent bien aux besoins des paquets.

DebConf: rolling et drapeaux de compilation renforcée

J’ai participé une semaine entière à la DebConf (du dimanche 24 au dimanche 31) et, comme à l’accoutumée, ce fut un plaisir de revoir mes amis de Debian. C’est toujours difficile de trouver le bon équilibre entre assister aux conférences, travailler au hacklab et développer les relations humaines, mais je suis plutôt content du résultat obtenu.

Je n’avais aucun but précis lorsque je suis arrivé, excepté animer une session de discussion (« BoF ») autour de Debian rolling (diapos et vidéos de la discussion) . Ceci étant, toutes les discussions lors des débats allongent la TODO list, et cette année ne fit pas exception à la règle. Le BoF du comité technique aborda certaines questions en suspens, dont une m’intéresse particulièrement : comment activer les drapeaux de compilation renforcée dans Debian (cf. n°552688).

Une autre discussion sur le sujet fut prévue le mardi et il en ressort que dpkg-buildflags constitue l’interface appropriée pour injecter ces drapeaux. À condition toutefois que ce dernier offre un moyen de laisser tomber les drapeaux indésirables et dispose d’une interface pratique pour les injecter via la commande ./configure.

Compte tenu de tous ces éléments, je me mis au travail pour implémenter ces nouvelles fonctionnalités, et préparai avec Kees Cook un patch d’activation de ces drapeaux par défaut. Il n’est pas encore prêt à être intégré dans la branche officielle, mais est déjà fonctionnel. (cf. mon dernier commentaire du bogue).

Quelques mots à propos du BoF sur rolling également. Les auditeurs venus en nombre témoignent, comme à l’habitude, de l’intérêt que suscite ce sujet. Le but que je souhaitais atteindre était assez limité : mesurer le poids et l’importance respective des différentes opinions exprimées lors de la dernière discussion fleuve sur debian-devel.

Il s’est avéré qu’une majorité significative des participants estiment testing utilisable dès à présent. Mais l’opportunité de lui faire une plus grande publicité recueille des avis plus partagés. Quant à la question de savoir si nous pouvons supporter un grand nombre d’utilisateurs de testing/rolling, peu s’estiment qualifiés pour répondre, mais ceux qui le croient répondent oui.

Encore du travail sur dpkg…

Réalisation de plein de petites choses :

  • J’ai encore fait du triage de bogues sur Launchpad. Brian Murray a abattu un travail monstre et le résultat est impressionnant : nous sommes descendus à environ 150 bogues (à comparer aux 300 et plus du mois précédent !);
  • J’ai mis à jour ma branche multiarch de nombreuses fois. J’espérais rencontrer Guillem pendant la DebConf, afin de faire quelques progrès dans ce domaine, mais il n’y participa malheureusement pas. À plusieurs reprises au cours de la semaine des personnes m’ont interpellé pour avoir des nouvelles sur son intégration;
  • J’ai corrigé une régression affectant update-alternatives (bogue n°633627), l’échec d’une suite de tests lorsque lancée en tant que root (#634961), et une erreur de segmentation dans findbreakcycle(). Un bon paquet d’améliorations mineures furent également de la partie (n°634510, 633539, 608260, 632937).

Système de suivi des paquets (PTS) et DEHS

Un remplaçant de DEHS a été écrit par Christoph Berg, car celui-ci n’était pas vraiment fiable, et pas sous contrôle de l’équipe en charge de la qualité. Pour ceux qui ne connaissent pas cet outil, il s’agit d’un système centralisé utilisant les fichiers debian/watch pour détecter les dernières versions amont des logiciels disponibles dans Debian.

J’ai mis à jour le Système de suivi des paquets (PTS – Package Tracking System), afin qu’il utilise ce nouvel outil en lieu et place de DEHS. Cela fonctionne bien, mais il manque encore les notifications par mail que DEHS envoyait. Si d’aventure quelqu’un voulait contribuer cette fonctionnalité, ce serait chouette !

Empaquetages divers

J’ai accompli quelques tâches préalables à la mise à jour du paquet WordPress vers la toute dernière version upstream (3.2). Il me reste à tester le paquet qui en résulte : remplacer les copies des bibiliothèques javascript/PHP fournies par les développeurs amont présente toujours des risques, et manque de chance, elles ont toutes subies des modifications dans le processus d’intégration.

J’ai également mis à jour nautilus-dropbox vers la version 0.6.8. J’ai également uploadé la version précédente (présente dans testing jusqu’alors) dans squeeze-backports. Un paquet Debian officiel est maintenant présent pour cette application dans toutes les distributions Debian (squeeze, wheezy, sid et experimental).

Merci

Au mois prochain pour un nouveau résumé de mes activités !

Ceci est une traduction de mon article My Debian activities in July 2011 contribuée par Weierstrass01. Ne manquez pas une occasion de parfaire vos connaissances de Debian ou Ubuntu, abonnez-vous à ma newsletter en cliquant ici.

Comment recompiler un paquet Debian

Savoir recompiler un paquet Debian existant est particulièrement utile. En effet, il s’agit là d’un prérequis indispensable à certaines tâches qu’un administrateur peut vouloir effectuer : activer une fonctionnalité désactivée dans le paquet Debian officiel, recompiler les sources pour un autre environnement (récupérer la version correspondant à Debian testing pour faire fonctionner le paquet sous Debian stable par exemple — ce qui, d’ailleurs, est le principe même des applications disponibles dans les backports), inclure une correction que les développeurs upstream ont mise à disposition, … Cet article vous propose de découvrir les 4 étapes nécessaires à cette recompilation :

1. Télécharger les sources

La « meilleure » manière de télécharger les sources reste l’utilisation d’APT. Il permet de les télécharger depuis les dépôts source paramétrés dans le fichier /etc/apt/sources.list, comme par exemple :

deb-src http://ftp.debian.org/debian unstable main contrib non-free
deb-src http://ftp.debian.org/debian testing main contrib non-free
deb-src http://ftp.debian.org/debian stable main contrib non-free

Comme on le voit, le premier mot-clé indique clairement à APT que l’on s’intéresse aux sources, et non pas aux binaires.

Si les dépôts source n’étaient pas présents dans le fichier auparavant, un petit apt-get update permettra de mettre à jour la base et vous pourrez récupérer par exemple la dernière version des sources du paquet publican, via la commande apt-get source publican. Il est également possible d’indiquer la distribution au sein de laquelle il faut récupérer les sources, avec la syntaxe « package/distribution« . Dans notre cas, apt-get source publican/testing récupérera les sources de publican à partir du dépôt testing et les extraira dans le répertoire courant (via la commande dpkg-source -x, avec comme prérequis le paquet dpkg-dev installé).

$ apt-get source publican/testing
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Note : la maintenance du paquet de « publican » est réalisée dans le système de suivi de versions « Git » à l'adresse :
git://git.debian.org/collab-maint/publican.git
Nécessité de prendre 888 ko dans les sources.
Réception de : 1 http://ftp.fr.debian.org/debian/ testing/main publican 2.5-2 (dsc) [2 292 B]
Réception de : 2 http://ftp.fr.debian.org/debian/ testing/main publican 2.5-2 (tar) [879 kB]
Réception de : 3 http://ftp.fr.debian.org/debian/ testing/main publican 2.5-2 (diff) [6907 B]
888 ko réceptionnés en 8s (104 ko/s)
dpkg-source: info: extraction de publican dans publican-2.5
dpkg-source: info: extraction de publican_2.5.orig.tar.gz
dpkg-source: info: extraction de publican_2.5-2.debian.tar.gz
dpkg-source: info: mise en place de perl-critic-fixes-svn1732
$ ls -dF publican*
publican-2.5/
publican_2.5-2.debian.tar.gz
publican_2.5-2.dsc
publican_2.5.orig.tar.gz

Si vous ne souhaitez pas utiliser APT, ou si le paquet source n’est pas hébergé par un dépôt APT, il est toujours possible de télécharger le paquet source complet via dget -u dsc-url, où dsc-url représente l’URL du fichier .dsc, image des sources du paquet. L’utilitaire dget est fourni par le paquet devscripts. L’option -u mérite d’être retenue : elle signifie que l’origine des sources ne sera pas vérifiée avant extraction.

2. Installer les dépendances de compilation

Là-aussi, APT peut faire le boulot ingrat à votre place. Tout ce que vous avez à faire est de lancer apt-get build-dep mon-paquet afin que les dépendances nécessaires à la compilation de mon-paquet soient installées. La syntaxe restant la même que pour apt-get source, il est possible de lancer apt-get build-dep publican/testing, ce qui aura pour effet d’installer les dépendances pour la compilation de la version testing de publican.

Si vous ne pouvez pas utiliser APT pour faire cela, placez-vous directement dans le répertoire contenant l’extraction du paquet source et lancez dpkg-checkbuilddeps. En sortie, vous aurez une liste de dépendances de compilation non satisfaites (dans le cas contraire, la commande restera muette, et vous pourrez continuer tranquillement). Dans ce cas, un enchaînement de copier/coller et d’apt-get install permettra de remédier au problème en quelques secondes.

3. Faites les modifications requises

Je ne détaillerai pas cette étape, dans la mesure où elle dépend totalement des objectifs particuliers qui vous poussent à recompiler. Vous serez peut-être amené à modifier le fichier debian/rules, ou à appliquer un patch.

Dans tous les cas, une chose est sûre : si vous avez changé quoi que ce soit, ou recompilé le paquet dans un environnement différent, vous devriez vraiment changer son numéro de version. dch --local perso (toujours du paquet devscripts) vous permet de le faire simplement : remplacer simplement perso par un nom court vous identifiant comme le pourvoyeur de cette version. debian/changelog sera modifié en conséquence et vous serez invité à documenter brièvement les changements opérés.

4. Compiler le paquet

La dernière étape est également la plus simple, maintenant que tout est en place. Vous devez vous placer à la racine du répertoire où sont extraites les sources, et lancer debuild -us -uc (procédure recommandée, nécessite le paquet devscripts), ou directement dpkg-buildpackage -us -uc. Les options « -us -uc » évitent l’étape de la signature qui provoquerait une erreur (bénigne) à la fin si vous ne disposez pas de clé GPG correspondant au nom entré au début du fichier des modifications Debian (debian/changelog).

$ cd publican-2.5
$ debuild -us -uc
dpkg-buildpackage: export de CFLAGS depuis dpkg-buildflags (origine : vendor): -g -O2
dpkg-buildpackage: export de CPPFLAGS depuis dpkg-buildflags (origine : vendor): 
dpkg-buildpackage: export de CXXFLAGS depuis dpkg-buildflags (origine : vendor): -g -O2
dpkg-buildpackage: export de FFLAGS depuis dpkg-buildflags (origine : vendor): -g -O2
dpkg-buildpackage: export de LDFLAGS depuis dpkg-buildflags (origine : vendor): 
dpkg-buildpackage: paquet source publican
dpkg-buildpackage: version source 2.5-2
dpkg-buildpackage: source changé par Raphaël Hertzog 
dpkg-buildpackage: architecture hôte amd64
[...]
dpkg-deb: compilation du paquet `publican' en `../publican_2.5-2rh1_all.deb'.
 dpkg-genchanges  >../publican_2.5-2rh1_amd64.changes
dpkg-genchanges: sources originales non incluses en version amont
 dpkg-source --after-build publican-2.5
dpkg-buildpackage: binary and diff upload (sources originales NON incluses)
Lancement de lintian...
lintian : terminé.

La compilation est terminée. Les sources mises à jour ainsi que les paquets binaires ont été générés dans le dossier parent.

$ cd ..
$ ls -dF publican*
publican-2.5/                    publican_2.5-2rh1.dsc
publican_2.5-2.debian.tar.gz     publican_2.5-2rh1_amd64.changes
publican_2.5-2.dsc               publican_2.5-2rh1_source.changes
publican_2.5-2rh1_all.deb        publican_2.5.orig.tar.gz
publican_2.5-2rh1.debian.tar.gz

Cet article est une traduction de Howto to rebuild Debian packages contribuée par Weierstrass01. Abonnez-vous à ce blog par RSS ou par email pour recevoir tous les prochains articles et améliorer votre maîtrise de Debian/Ubuntu.

Le plan secret derrière le format de paquet source Debian « 3.0 (quilt) »

New source package formats do wondersBien qu’ayant passé un nombre incalculable d’heures au développement du nouveau format source connu sous le nom de « 3.0 (quilt) », je n’ai réalisé que récemment que je n’avais encore rien écrit quant aux motivations qui m’ont conduit à le faire. Oubli auquel cet article va remédier.

Le bon vieux format « 1.0 »

Jusqu’en 2008, dpkg-source n’était capable de gérer qu’un seul format source, maintenant connu comme le « 1.0 ». Il s’agissait du format utilisé depuis le commencement du projet et, bien que fonctionnant sans problème dans la majorité des cas, il souffrait d’un certain nombre de limitations. Ceci principalement parce qu’il gérait l’empaquetage Debian comme un patch devant être appliqué par dessus le tarball source originel.

Ce patch pouvait avoir deux fonctions : créer les fichiers requis dans le sous-répertoire Debian et appliquer les modifications aux sources upstream. Mais au fil du temps, si le mainteneur du paquet procédait à plusieurs modifications du code source d’origine, ces dernières atterrissaient pêle-mêle — et sans documentation — dans ce seul patch. Des systèmes de gestion des patchs (dpatch, quilt, simple-patchsys, dbs, …) furent créés pour remédier à ce problème, et de nombreux mainteneurs commencèrent à les utiliser. L’implémentation diffère légèrement d’un système à l’autre, mais le principe de base reste le même : conserver les modifications des sources originales comme autant de patchs dans le dossier debian/patches/ et les appliquer à la compilation (et les enlever dans la règle clean en charge du nettoyage de l’arborescence).

Objectifs des nouveaux formats

Lorsque j’ai commencé à travailler sur le nouveau format source, j’avais comme objectif de m’affranchir des limitations connues et d’intégrer un système de gestion des patchs à dpkg-source. Je tenais à clarifier la situation de telle sorte que le fait d’apprendre à empaqueter ne nécessitait la connaissance que d’un seul système de patchs, et ne passait plus par la modification des debian/rules pour utiliser ce dernier. Je choisis quilt dans la mesure où il était populaire, disposait d’un large panel de fonctionnalités, et ne souffrait pas du syndrome du NIH. Tout cela conduisit au format source « 3.0 (quilt) ».

Dans le même temps naquit « 3.0 (native) » en tant que format distinct. Le format « 1.0 » était capable de générer deux types de paquet sources (natif et non-natif), mais je ne tenais pas à faire perdurer ce mélange des genres au sein d’un même format. Le principe du KISS édicte que l’utilisateur doit sélectionner le format de son choix, le mettre dans debian/source/format et c’est tout. Point final. Maintenant la compilation peut légitimement échouer lorsque les pré-requis ne sont pas satisfaits, plutôt que de basculer vers un « plan B » consistant en comportements inattendus.

Fonctionnalités du format « 3.0 (quilt) »

Il s’agit du format remplaçant le format 1.0 (non-natif). Les fonctionnalités ci-dessous sont spécifiques au nouveau format et le différencient de son ancêtre :

  • Support des formats de compression autres que gzip: bzip2, lzma, xz;
  • Utilisation de plusieurs tarball amont possible;
  • Inclusion de fichiers binaires dans l’empaquetage Debian possible;
  • Remplacement automatique du dossier « debian » dans le tarball amont (aucun ré-empaquetage nécessaire);
  • Création d’un patch (au standard quilt) dans debian/patches/ lorsque des changements par rapport aux fichiers upstream sont rencontrés.

Fonctionnalités du format « 3.0 (native) »

Ce format est très similaire à la variante « native » du format « 1.0 », excepté sur deux points :

  • Support des formats de compression autres que gzip: bzip2, lzma, xz;
  • Exclusion automatique des fichiers ne devant normalement pas faire partie du paquet (fichiers spécifiques aux VCS, fichiers de sauvegarde vim, …).

Chronologie

Un petit retour sur l’histoire de ce projet est intéressant. Celui-ci a déjà quelques années d’activité et ne pourra être considéré comme terminé uniquement lorsqu’une majorité de paquets auront migré vers les nouveaux formats.

  • Janvier 2008 : la discussion Comment gérer les patchs convenablement enflamme la liste de diffusion debian-devel@lists.debian.org. Le résultat de cette discussion constitue mes orientations initiales;
  • Mars 2008 : Je finis de concevoir les nouveaux formats et je lance un appel à retours d’utilisation. dpkg 1.14.17 (uploadé dans experimental) est la toute première version les supportant;
  • Avril 2008 : Demande aux ftpmasters via le ticket n°457345 de supporter les nouveaux formats de paquet source;
  • Juin 2008 : gel de Lenny. dpkg n’est plus supposé connaître de changements. Plusieurs changements concernant les nouveaux formats source sont cependant acceptés dans les mois qui suivent dans la mesure où ce code n’est, d’une part, pas encore utilisé en production, et d’autre part, car sa présence n’est requise que dans la mesure où elle doit permettre à Lenny de gérer les nouveaux formats lorsque Squeeze aura commencé à les utiliser;
  • Février 2009 : publlication de Lenny.
  • Mars 2009 : le travail sur Squeeze a débuté, mais les ftpmasters n’ont toujours rien fait concernant le support des nouveaux formats. Je soumets un patch à la suite du ticket n°457345 pour accélérer les choses. Je mets en place une page wiki pour suivre l’avancement du projet et répondre aux questions usuelles des mainteneurs de paquets;
  • Novembre 2009 : Après un sprint des ftpmasters, il est alors possible d’uploader des paquets aux nouveaux formats sources dans unstable. Cela focalise l’attention sur les nouveaux formats et certaines personnes commencent à se plaindre de certaines décisions de conception. L’implémentation du format « 3.0 (quilt) » change considérablement durant ce mois. La version de dpkg dans Lenny est même mise à jour pour la garder synchronisée avec ces changements;
  • Mars 2010 : je prévoyais jusque-là de laisser dpkg-source compiler lui-même les nouveaux paquets source dans le futur. Après plusieurs échanges, je conçois que cela ne constitue pas la meilleure manière de procéder et rend à la place obligatoire le fichier debian/source/format. Le mainteneur doit explicitement désigner le format source qu’il souhaite utiliser;
  • Octobre 2010 : Les nouveaux formats source sont relativement populaires : un tiers des paquets source ont déjà changé de format, cf. ce graphique. Le gel de Squeeze en août a clairement stoppé la dynamique;
  • Février 2011: Publication de Squeeze, les mainteneurs peuvent à nouveau faire évoluer leur paquets et le taux de conversion des paquets repart à nouveau.
  • Juin 2013 : fin du projet ?

Comme vous pouvez le constater, le projet n’est pas encore terminé, bien que la partie la plus difficile soit passée. En ce qui me concerne, le plus grand enseignement que j’en retire est que vous n’aurez jamais suffisamment de retour tant que votre travail n’est pas dans unstable. Aussi, si vous menez un projet Debian impactant un grand nombre de personnes, assurez-vous d’organiser un processus de revue officiel dès le début. Une des meilleures manières de le faire consiste probablement à décrire votre projet à travers une Proposition d’amélioration de Debian.

Si vous appréciez les efforts que j’ai consacrés à ce projet, n’hésitez pas à ouvrir un compte Flattr et à soutenir dpkg de temps en temps. Ou à visiter ma page « Soutenir mon travail« .

Cet article est une traduction de The secret plan behind the « 3.0 (quilt) » Debian source package format contribuée par Weierstrass01.

Comment créer des paquets Debian avec une méthode de compression alternative

Alors que gzip vient immédiatement à l’esprit quand il s’agit de compression de fichiers, d’autres outils existent et permettent même d’atteindre un meilleur ratio de compression que celui-ci. Cet article explique comment tirer parti de ces alternatives dans votre travail d’empaquetage Debian.

Dans le paquet source

Un paquet source se compose de plusieurs fichiers. Le fichier .dsc n’est jamais compressé, ce qui ne pose aucun problème puisqu’il s’agit d’un petit fichier texte. Outre via gzip (orig.tar.gz), les archives TAR amont peuvent être compressés grâce à bzip2 (orig.tar.bz2), lzma (orig.tar.lzma) ou xz (orig.tar.xz). À vous de choisir si l’archive amont est proposée sous différents formats de compression. Placez-le au bon endroit et dpkg-source l’utilisera automatiquement. Il est à noter toutefois que dans le cas du format source 1.0 seul gzip est utilisable, tandis que l’archive principale Debian n’autorise actuellement que gzip et bzip2 (xz suivra éventuellement plus tard), même si le format source « 3.0 (quilt) » les supporte tous.

Les fichiers d’empaquetage Debian sont fournis soit sous forme de fichier .diff.gz pour le format source 1.0 (seul gzip est supporté ici aussi), soit sous forme de fichier .debian.tar pour le format source « 3.0 (quilt) ». Cette dernière archive pouvant être compressée via l’outil de votre choix, il suffit de le spécifier à dpkg-source (cf. ci-dessous. À noter que la valeur par défaut correspond à l’utilisation de gzip).

Dpkg-source doit générer l’archive principale dans le cas d’un paquet natif et il est possible de lui faire utiliser autre chose que gzip, grâce à l’option --compression. Cette option est usuellement placée dans le fichier debian/source/options:

# Utilisation de bzip2 au lieu de gzip
compression = "bzip2"
compression-level = 9

Cette option n’est généralement pas très utile dans le cas des paquets sources au format « 3.0 (quilt) », dans la mesure où l’archive Debian compressée n’est pas d’une taille importante. Ceci étant, certains mainteneurs préfèrent utiliser le même outil de compression pour l’archive amont et l’archive Debian. Vous êtes donc libre d’utiliser cette option dans un souci d’harmonisation.

C’est par contre bien plus intéressant dans le cas des paquets natifs : pour exemple la taille du paquet source dpkg a été réduite de 30% en passant à bzip2, sauvant ainsi 2Mo d’espace disque.

Dans les paquets binaires

Les fichiers .deb contiennent également des archives compressées au format tar, et utilisent également gzip par défaut :

$ ar t dpkg_1.15.8.9_i386.deb 
debian-binary
control.tar.gz
data.tar.gz

L’archive data.tar.gz contient tous les fichiers à installer, et c’est précisément celle que vous pouvez compresser via un outil alternatif à gzip. Rappelons que ce n’est vraiment intéressant que dans le cas des — très — gros paquets, dont la taille justifie l’écart par rapport au processus standard de compression. Essayez et regardez un peu combien de Mo vous parvenez à sauver ! Le fait que ces alternatives puissent nécessiter une quantité importante de mémoire (que ce soit pour la compression ou la décompression) ne doit pas être négligé : dans le cas de plate-formes embarquées ou de matériels d’entrée de gamme disposant de peu de mémoire, il peut être intéressant de conserver gzip.

Ceci étant dit, quelle est donc la manière de procéder ? Rien de plus facile, dpkg-deb met à disposition l’option -Z, à laquelle il suffit de passer « -Zbzip2 » par exemple. Il est également possible de passer « -z6 » pour changer le ratio de compression à 6 (ce qui peut être utile car un niveau de compression inférieur peut entraîner une empreinte mémoire plus faible, selon le programme utilisé). L’invocation de dpkg-deb étant habituellement masquée derrière l’appel à dh_builddeb dans le fichier /debian/rules, il faut modifier ce dernier avec « dh_builddeb -- -Zbzip2 ».

Si vous utilisez les fichiers de règles de debhelper 7, il vous faudra neutraliser le comportement standard via par exemple l’ajout de :

%:
	dh $@

override_dh_builddeb:
	dh_builddeb -- -Zbzip2

Si vous utilisez CDBS, la variable d’environnement DEB_DH_BUILDDEB_ARGS doit être initialisée à :

include /usr/share/cdbs/1/rules/debhelper.mk
[...]
DEB_DH_BUILDDEB_ARGS = -- -Zbzip2

Cet article est une traduction de How to create Debian packages with alternative compression methods contribuée par Weierstrass01. Abonnez-vous à ce blog par RSS ou par email pour recevoir tous les prochains articles et améliorer votre maîtrise de Debian/Ubuntu.

Comment ajuster le comportement de dpkg-source dans un paquet source Debian

Dpkg-source est le programme chargé de générer un nouveau paquet source Debian lors d’un changement de version. Bien qu’il offre de nombreuses options intéressantes en ligne de commande, celles-ci ne sont que rarement utilisées… faute de savoir comment faire pour que ces options soient systématiquement utilisées ! Nous allons voir comment y remédier.

Solution la plus évidente : passer des options à dpkg-source via la ligne de commande de dpkg-buildpackage. L’inconvénient étant bien sûr qu’il faut s’en rappeler à chaque fois ! On peut partiellement y remédier en créant des alias shell incluant ces options. Mais il faudra autant d’alias que de combinaisons d’options. Pas très pratique…

La solution adéquate a été implémentée l’année dernière, à partir de la version 1.15.5 de dpkg. Elle consiste à entrer ces options dans debian/source/options. N’importe quelle option commençant par « -- » peut y être incluse, à raison d’une option par ligne, « -- » étant omis. Exemple :

# Utilisation de la compression Bzip2 pour debian.tar
compression = "bzip2"
compression-level = 7
# Pas de diff pour les modifications de config.(sub|guess)
extend-diff-ignore = "(^|/)config.(sub|guess)$"

À noter : l’utilisation d’espaces autour du signe égal est ici possible, contrairement à la ligne de commande. L’encadrement de la valeur par des guillemets est possible mais non obligatoire.

Au final, debian/source/options faisant parti du paquet source, n’importe qui d’autre le récupérant générera le paquet avec les options que vous aurez entrées dans ce fichier.

Le même résultat peut être obtenu en utilisant le fichier debian/source/local-options. La seule différence étant que ce fichier ne sera pas inclus dans le paquet source, ce qui peut être intéressant si vous travaillez avec un logiciel de gestion de versions (VCS, Version Control Repository) tel que git, svn, bazaar etc… avec des options que les utilisateurs finaux ne doivent pas passer. Certaines options (telle que --unapply-patches) ne sont autorisées que dans ce fichier, pour ne pas surprendre l’utilisateur du paquet source généré avec un comportement inattendu.

Vous pourrez en apprendre bien plus sur les options de dpkg-source en consultant sa page de manuel. Je suis persuadé que vous y découvrirez des options qui vous sont inconnues ! Saviez-vous, par exemple, que vous pouviez demander à dpkg-source d’interrompre le processus s’il détectait que certaines modifications amont n’étaient pas gérées par un patch existant dans debian/patches ? Il s’agit de l’option --abort-on-upstream-changes, et elle ne peut être utilisée que dans le fichier debian/source/local-options.

Cet article est une traduction de How to customize dpkg-source’s behaviour in your Debian source package contribuée par Weierstrass01. Abonnez-vous à ce blog par RSS ou par email pour recevoir tous les prochains articles et améliorer votre maîtrise de Debian/Ubuntu.

Comment utiliser plusieurs archives amont dans les paquets source Debian

Depuis l’introduction du format source « 3.0 (quilt) », il est maintenant possible d’intégrer plusieurs archives amont dans les paquets source Debian. Cet article a pour but de vous montrer comment faire avec votre propre paquet, étant donné qu’il est assez utile d’intégrer facilement des plugins, traductions ou documentations que les développeurs amont mettent à disposition sous forme d’archives séparées.

Explications pas-à-pas

Les sources de Spamassassin serviront d’exemple. La version en développement est la 3.3.1. L’archive principale est nommée de manière conventionnelle (spamassassin_3.3.1.orig.tar.gz) et contient le dossier racine des sources. Nous avons déjà un répertoire Debian dans la mesure où le paquet n’est pas nouveau.

Les développeurs mettent à disposition les règles spamassassin sous la forme d’une archive séparée nommée Mail-SpamAssassin-rules-3.3.1.r901671.tgz. On la récupère, la renomme spamassassin_3.3.1.orig-pkgrules.tar.gz et la copie dans le même répertoire que l’archive principale. Le suffixe « pkgrules » est non seulement la « clé » identifiant clairement l’archive amont, mais aussi le nom du dossier dans lequel il sera extrait à l’intérieur du paquet source. Un tel répertoire n’existant pas encore, nous devons le créer.

$ mv Mail-SpamAssassin-rules-3.3.1.r901671.tgz spamassassin_3.3.1.orig-pkgrules.tar.gz
$ cd spamassassin-3.3.1
$ mkdir pkgrules
$ tar -C pkgrules -zxf ../spamassassin_3.3.1.orig-pkgrules.tar.gz

Et cela suffit ! La prochaine fois que le paquet source sera généré, l’archive supplémentaire sera automatiquement intégrée dans le paquet.

$ dpkg-buildpackage -S
[...]
 dpkg-source -b spamassassin-3.3.1
dpkg-source: info: utilisation du format source « 3.0 (quilt) »
dpkg-source: info: construction de spamassassin à partir de ./spamassassin_3.3.1.orig-pkgrules.tar.gz ./spamassassin_3.3.1.orig.tar.gz
dpkg-source: info: construction de spamassassin dans spamassassin_3.3.1-1.debian.tar.gz
dpkg-source: info: construction de spamassassin dans spamassassin_3.3.1-1.dsc

L’archive supplémentaire est maintenant partie intégrante des sources mais, en l’état, ne sert à rien… il faut modifier le fichier debian/rules (ou debian/spamassin.install) pour installer les nouveaux fichiers dans le paquet binaire.

Un cas particulier : l’empaquetage d’un ensemble de logiciels connexes

Dans de très rares cas, vous pouvez être amenés à empaqueter ensemble plusieurs programmes (de petits modules Perl par exemple) et vous n’avez aucune archive principale, seulement plusieurs petites. Renommez-les selon la logique précédente, puis demandez à dpkg-source, lors de la génération du paquet, de créer une archive principale « factice » avec l’option --create-empty-orig :

$ dpkg-buildpackage -S --source-option=--create-empty-orig

Utilisez cette option avec précaution dans la mesure où le numéro de version que vous donnez au lot de programmes est très vraisemblablement décorrélé de celui de chaque programme.

Erreurs fréquentes

Oublier d’extraire les archives supplémentaires

Si vous oubliez d’extraire le contenu de l’archive supplémentaire dans le répertoire pkgrules, dpkg-source émettra de nombreux messages d’avertissement concernant la suppression des fichiers de cette archive. Il ne s’agit pas réellement d’une suppression, vous avez simplement oublié de les créer dans le répertoire précédent.

dpkg-source: avertissement: suppression du répertoire pkgrules ignorée
dpkg-source: avertissement: suppression du fichier pkgrules/20_fake_helo_tests.cf ignorée
dpkg-source: avertissement: suppression du fichier pkgrules/60_shortcircuit.cf ignorée
[...]

Mauvais numéro de version pour l’archive supplémentaire

Parfois l’archive supplémentaire se trouve dans une version ne correspondant pas à la version en développement. Vous devez nommez le fichier de façon cohérente avec la source amont, car dans le cas contraire il ne sera pas pris en compte par dpkg-source. Ce dernier générera un nouveau patch dans debian/patches contenant l’intégralité du nouveau dossier.

Rendre le nom du composant significatif en regard du numéro de version de l’archive supplémentaire est une solution possible (dans notre exemple ci-dessus, nous aurions pu ainsi adopter le suffixe « pkgrules-r901671″). Le revers de la médaille consiste en un nom de dossier variable, changeant avec toute nouvelle version. Le corollaire étant bien sûr que vous devrez adapter vos règles d’empaquetage pour prendre en compte ce changement.

Ceci étant, cette astuce a le mérite de permettre la mise à jour du contenu additionnel sans pour autant impacter la version amont. L’envoi d’une nouvelle révision sera acceptée dans la mesure où l’archive principale sera ignorée — car inchangée — tandis que le contenu additionnel sera mis à jour (du fait du nom différent).

Assurez-vous cependant de retirer les anciennes versions des archives additionnelles, sans quoi vous auriez plusieurs copies différentes de la même archive dans votre paquet source !

Mauvaise extraction de l’archive supplémentaire

Vous devez faire preuve d’autant d’ingéniosité que dpkg-source lorsque vous extrayez manuellement l’archive supplémentaire !

Si l’archive contient uniquement un répertoire racine, celui-ci est extrait, renommé pour correspondre au nom du composant et déplacé dans le répertoire du paquet source.
Dans le cas contraire (plusieurs répertoires à la racine), alors le répertoire de destination est créé en premier et le contenu de l’archive directement extrait dans celui-ci.

Ci-dessous des commandes pour faire face dans tous les cas (le répertoire courant est supposé être celui du paquet source) :

$ mkdir pkgrules
# L'archive contient un unique répertoire de premier niveau
$ tar -C pkgrules --strip-components=1 -zxf ../spamassassin_3.3.1.orig-pkgrules.tar.gz
# L'archive contient plusieurs fichiers/répertoires au premier niveau
$ tar -C pkgrules -zxf ../spamassassin_3.3.1.orig-pkgrules.tar.gz

Cet article est une traduction de How to use multiple upstream tarballs in Debian source packages contribuée par Weierstrass01. Abonnez-vous à ce blog par RSS ou par email pour recevoir tous les prochains articles et améliorer votre maîtrise de Debian/Ubuntu.