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.

Gérer des patchs spécifiques à chaque distribution avec un paquet source commun

Un patch peut-il n’être appliqué au paquet cible que pour certaines distributions ? Cette question m’a été posée en commentaire d’un précédent article présentant la gestion différentielle des dépendances entre Ubuntu et Debian, à partir d’un même paquet source. Et la réponse est … oui. C’est possible !

Le format de paquets source 3.0 (quilt) offre à cette fin une possibilité intéressante : plutôt que d’utiliser uniquement le fichier debian/patches/series pour rechercher des patches, dpkg-source essaye en premier lieu d’utiliser debian/patches/distrib.series, où « distrib » vaut « ubuntu », « debian », … Il est important de noter que dpkg-source n’applique pas les patches de tous les fichiers series trouvés : seuls les patches du premier fichier trouvé sont considérés.

Bien, mais comment tirer le meilleur parti de tout cela ? Debian est supposée toujours fournir le fichier debian/patches/series, ce dernier devant indiquer l’ensemble des patches « de base » à appliquer. N’importe quel tiers travaillant avec Debian peut maintenir son propre fichier series dans le dépôt CVS commun de maintenance des paquets. Il peut ainsi laisser de côté certains patches propres à Debian (les patches relatifs à la marque, par exemple), et intégrer les siens en plus des patches restants.

Il est intéressant de noter que c’est au mainteneur de s’assurer, en cas de besoin, de la cohérence des deux fichiers. dpkg-source n’offre ni la possibilité d’agréger plusieurs fichiers series, ni d’établir une quelconque dépendance entre eux.

Pour éditer un fichier series alternatif grâce à quilt, il suffit de positionner temporairement la variable d’environnement QUILT_SERIES à « distrib.series ». Faites simplement attention à bien partir d’un état vierge (i.e. aucun patch appliqué). Si tel n’est pas le cas, quilt sera confronté à une incohérence entre les données du fichier series et ses propres données (stockées dans le dossier .pc).

Ceci est une traduction de mon article Managing distribution-specific patches with a common source package contribuée par Weierstrass01. Si vous avez apprécié cet article, cliquez ici pour découvrir comment m’encourager à en rédiger d’autres.

Mes activités Debian en mai 2011

Voici mon récapitulatif mensuel de toutes mes activités gravitant autour de Debian. Si vous faites partie des personnes m’ayant fait un don pour soutenir mon travail, 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.

Au cours du mois de mai, j’ai donc…

…un peu travaillé sur le concept de Debian Rolling

Les discussions au sujet de Debian Rolling étaient encore très actives en début de ce mois sur la liste debian-devel. L’idée de renommer testing en rolling (ce que je soutenais) n’a pas prévalu car certains jugeaient que des bugs Release Critical restaient ouverts trop longtemps dans cette distribution et me méritait donc pas ce label. La proposition la plus consensuelle a été celle de Josselin Mouette : elle consiste à bâtir la distribution rolling d’après testing, en y ajoutant quelques paquets choisis de unstable.

Je considère cette solution viable à la condition de la restreindre à un sous-ensemble précis d’architectures. Dans le cas contraire, les raisons pour lesquelles les paquets ne migrent pas vers testing impacteront rolling de la même manière. Et si ces raisons n’existent pas, alors autant effectuer les migrations correspondantes directement dans testing au lieu de rolling.

Étant donné ce qui précède, j’ai installé sur mon ordinateur portable britney — le logiciel qui contrôle testing — pour voir comment créer rolling avec cet outil. britney s’avère être un logiciel très spécialisé, avec très peu de possibilités de paramétrage.

Au même moment, Joachim Breitner fit une proposition qui attira immédiatement mon attention. Il suggère d’utiliser les solveurs SAT pour déterminer l’ensemble des paquets devant migrer de unstable vers testing. rolling peut être, à mon sens, un excellent banc d’essai pour cette nouvelle implémentation de britney (qu’il nomme ici SAT-britney). J’ai donc embarqué sans hésiter à bord de ce projet.

Les notions scientifiques sous-tendant le concept m’étant peu familières, j’ai compulsé de la documentation et appris que tous les solveurs SAT intégraient le problème sous une forme bien particulière, appelée Forme Normale Conjonctive. De plus, le format DIMACS est le format de fichiers retenu pour présenter ces contraintes booléennes. Plusieurs solveurs SAT sont disponibles pour Debian, et picosat semble être un des meilleurs.

J’ai donc commencé à coder pour voir comment appliquer le concept, le résultat est disponible dans ce dépôt git. Vous pouvez en récupérer une copie via git clone git://git.debian.org/~hertzog/sat-britney.git.

Il n’y a pas encore grand chose, excepté un peu de code (en Python) générant un problème SAT pouvant être passé à un solveur. Mais je suis impatient de voir les développements de ce projet.

…représenté Debian au salon Solutions Linux

J’ai passé 3 jours à Paris dans la deuxième semaine du mois de mai, pour prêter main forte à la tenue du stand Debian au salon Solutions Linux

Nous avons répondu à beaucoup de questions mais la majorité des visiteurs connaissaient déjà Debian, et beaucoup l’utilisent à la maison et/ou au travail. Nous avons essayé de recruter de nouveaux adhérents dans l’association Debian France, et vendu les goodies qui nous restaient.

Les représentants d’Ubuntu ont été interviewés par France 3, et nous avons profité de l’opportunité (avec leur accord !) pour exhiber nos t-shirts Debian à l’arrière-plan. La vidéo est disponible ici, et vous pouvez nous y voir (Carl Chenet et moi-même) à 1:21.

Nous avons été interviewés quant à nous par Intelli’n TV: une première vidéo et une seconde. J’avoue ne pas exceller dans cet exercice ! :-)

…amélioré les triggers dpkg

La troisième semaine de mai était une semaine de vacances, et j’aurai du me tenir loin de mon ordinateur. Mais je tenais vraiment à la mettre à profit pour améliorer l’état des triggers dpkg dans Debian.

J’ai déjà abordé mon travail dans un précédent article : Trying to make dpkg triggers more useful and less painful.

Dans l’attente d’une synthèse des réponses à la question que j’ai envoyée à tous les mainteneurs de paquets utilisant les triggers, je n’ai pas encore intégré le résultat de mon travail dans le dépôt officiel.

…aidé les utilisateurs suite à la migration d’Alioth

Lorsque je suis revenu de vacances, un certain nombre de services fournis par alioth.debian.org étaient non-fonctionnels après la migration vers un nouvel environnement, impliquant deux machines au lieu d’une auparavant. Étant donné que je fus longtemps un administrateur d’Alioth, je suis bien placé pour savoir qu’en de telles circonstances, vous vous retrouvez vite submergé par les demandes de support utilisateur. Je suis donc retourné sur le canal #alioth d’IRC afin d’aider au mieux.

J’ai investigué certains des problèmes soulevés et mis au point des corrections (scripts mis à jour, fichiers de configuration, etc.) pour quelques-uns d’entre eux. J’ai également créé une liste des problèmes restants. Elle n’aurait du exister que quelques jours mais, en raison de régressions encore non résolues, est toujours active.

Les fonctionnalités les plus importantes manquant encore sont :

  • un support propre pour la délégation des droits. Par le passé, nous utilisions les ACL mises en place par les administrateurs. Avec le nouveau FusionForge, chaque admin de projet devrait être capable de déléguer des droits à des « rôles » extérieurs. Un rôle « Développeur Debian » existe déjà, mais la délegation echoue… ;
  • l’accès à l’Ultimate Debian Database. De nombreux outils s’appuient sur cette base de données pour fonctionner ;
  • l’accès en FTP anonyme pour télécharger les fichiers des projets ;
  • des directives claires sur la manière dont nous sommes censés gérer les sites web mis à jour à travers des hooks VCS ;
  • des directives claires sur la manière dont nous sommes supposés gérer les dépôts git personnels.

…amélioré le format de paquet source « 3.0 (quilt) »

J’ai émis plusieurs propositions visant à modifier le comportement du nouveau format source. L’objectif visé est double : premièrement, le rendre moins pénible à l’utilisation pour les empaqueteurs utilisant un VCS, et, deuxièmement, éviter les changements non souhaités qui s’immisceraient via un nouveau patch généré par dpkg-source.

Ces propositions semblent être consensuelles, je pourrai donc les implémenter dans un avenir proche.

…un peu laissé de côté la version anglaise de mon blog

Beaucoup de travail a été abattu pour Debian entre les déplacements et les vacances et, dans le temps restant, je n’ai pas réussi à écrire beaucoup de nouveaux articles pour mon blog anglophone.

En fait, mis à part l’article sur les triggers mentionné précédemment, je n’ai publié qu’une interview : People behind Debian: Steve Langasek, release wizard.

Je vais essayer de faire mieux ce mois-ci !

Merci !

Un grand merci à ceux qui m’ont soutenu à hauteur de 151.61 € durant le mois de mai.

Rendez-vous le mois prochain pour un nouveau compte-rendu de mes activités Debian !

Cet article est une traduction de My Debian activities in May 2011 contribuée par Weierstrass01.

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 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.