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.

Le Cahier de l’Admin Debian Squeeze est disponible

Nous n’avons pas réussi à renouveler le tour de force de sortir le livre moins d’un mois après la sortie de la nouvelle version de Debian… c’est donc avec quelques mois de retard par rapport à la publication de Debian Squeeze que j’ai le plaisir de vous annoncer la disponibilité d’une nouvelle édition de mon livre.

Cette cinquième mouture du livre a été mise à jour pour tenir compte des changements introduits par la version 6.0 de Debian. Il bénéficie également de nouvelles sections traitant des technologies de virtualisation KVM et de LXC.

Le livre est disponible immédiatement en librairie, mais je vous invite à faire un tour sur la page officielle du livre pour découvrir des extraits, le sommaire, le quatrième de couverture, des témoignages de lecteurs, etc.

Une traduction en anglais à venir

Grâce au soutien de plusieurs centaines de personnes, la campagne de financement de la traduction a atteint son premier objectif et nous sommes désormais certains que le livre sera traduit en anglais.

Une libération possible

Cette campagne poursuit son cours jusqu’au 27 novembre, et est désormais animée par un second objectif : la publication sous licence libre du livre traduit. Pour cela il faut que le fond de libération atteigne 25000 € et nous en sommes à un peu plus de 11000 € (soit environ 45% de l’objectif).

Cliquez ici pour apporter votre contribution dans cette campagne de libération. Signalons qu’en retour vous pouvez obtenir une copie de ce livre (la version française est incluse dans la contrepartie à 50€).

Ne créez pas votre paquet Debian avec dpkg -b

J’ai pu observer de nombreuses personnes, ces dernières années, essayant d’utiliser dpkg --build pour créer des paquets Debian. Et, de fait, si vous lisez les pages de manuel de dpkg et de dpkg-deb, l’option semble bien appropriée à cet usage :

-b, --build répertoire [archive|répertoire]

Crée une archive Debian avec l’arborescence contenue dans répertoire. répertoire doit posséder un sous-répertoire DEBIAN qui contient les fichiers de contrôle tel que le fichier « control » lui-même. Ce répertoire n’apparaît pas dans l’archive de l’arborescence du paquet binaire ; mais les fichiers qu’il contient sont mis dans la zone de contrôle du paquet binaire.

On peut en conclure que oui, effectivement, dpkg-deb est l’outil créant en dernière étape les fichiers .deb (aussi connus sous le nom de paquets binaires). Ce qui ne veut pas dire que vous êtes censé appeler un tel outil « bas-niveau » vous-même. En effet, si vous souhaitez empaqueter proprement un logiciel, vous devez plutôt créer un paquet source Debian, qui partira du code source amont pour créer des paquets binaires respectant la charte technique Debian.

Créer un tel paquet source implique également de préparer une arborescence de répertoires (mais avec un sous-répertoire « debian »), ce qui est probablement plus compliqué que d’appliquer dpkg -b à un répertoire ciselé « à la main ». Mais le résultat en est d’autant plus versatile : les outils utilisés apportent une valeur ajoutée en analysant/modifiant dynamiquement les fichiers à l’intérieur de votre paquet (par exemple, les dépendances envers les bibliothèques C requises par votre paquet sont insérées automatiquement).

Si cette méthodologie vous était inconnue, vous souhaiterez peut-être approfondir le sujet grâce au manuel du Nouveau Mainteneur ou à la Charte Debian.

Ceci est une traduction de mon article Avoid a newbie packager mistake: don’t build your Debian packages with dpkg -b 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.

Garder un système Debian propre, astuce n°6 : supprimer les paquets automatiquement installés devenus inutiles

Pour le dernier billet de cette série, et après avoir vu comment débarrasser son système des fichiers ne provenant pas d’un paquet Debian, nous allons voir aujourd’hui comment nettoyer les paquets ayant été installés comme dépendances, et dont vous n’avez plus besoin.

APT garde automatiquement la trace de l’installation des paquets

Vous n’installez que rarement un paquet tout seul : lorsque vous en sélectionnez un dans apt-get/aptitude/synaptic, ces derniers vous en rajoutent la plupart du temps plusieurs – ses dépendances, sans lesquelles ils ne veulent pas installer celui qui vous intéresse. Un exemple :

$ sudo apt-get install pino
[...]
Les paquets supplémentaires suivants seront installés :
  libdbusmenu-glib1 libgee2 libindicate4 libnotify1 notification-daemon
Les NOUVEAUX paquets suivants seront installés :
  libdbusmenu-glib1 libgee2 libindicate4 libnotify1 notification-daemon pino
0 mis à jour, 6 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 478 kB dans les archives.
Après cette opération, 2531 kB d'espace disque supplémentaires seront utilisés.
Souhaitez-vous continuer [O/n] ? 

Les 5 paquets « supplémentaires » seront marqués à la fin de l’installation comme ayant été « automatiquement installés ». Qu’est-ce que cela signifie ? Tout simplement que vous n’avez pas explicitement demandé leur installation. Et, par conséquent, cela autorise le système à les retirer dès qu’il n’en a plus besoin.

apt-mark showauto, qui retourne une liste des paquets installés automatiquement, permet de vérifier que c’est bien le cas :

$ apt-mark showauto |grep libdbusmenu
libdbusmenu-glib1
$ apt-mark showauto |grep pino
$

aptitude montre cette information via la lettre « A » en regard du paquet (dans son interface ncurses), et nommément dans sa sortie en ligne de commande, par exemple aptitude show :

$ aptitude show libdbusmenu-glib1
Paquet : libdbusmenu-glib1               
Nouveau : oui
État: installé
Automatiquement installé: oui
Version: 0.3.7-1
[...]

L’information est moins visible dans synaptic : vous pouvez y avoir accès en sélectionnant un paquet installé, et en vérifiant dans le menu « paquet » si la case « installé automatiquement » est cochée ou non.

APT liste les paquets qui ne sont plus nécessaires

Certains paquets installés automatiquement peuvent, au fil du temps, ne plus être requis, car les paquets qui autrefois en dépendaient ne les appellent plus. Ce peut être car ils dépendent d’une version plus récente de la même bibliothèque, qu’ils dépendent d’autre chose pour assurer la même fonction, ou bien qu’ils sont dorénavant capables d’assurer tout seul la fonction.

Bref, quelle qu’en soit la raison, la dépendance originelle n’est plus, et le paquet automatiquement installé n’est plus requis pour le bon fonctionnement du système.

aptitude supprime automatiquement (à son prochain lancement) dans ce cas les paquets devenus inutiles, ce qui n’est pas le cas d’apt-get ou de synaptic.

apt-get, quant à lui, vous dresse par contre la liste des paquets superflus, et vous dit même parfois comment vous en débarrasser :

$ sudo apt-get remove pino
[...]
Les paquets suivants ont été installés automatiquement et ne sont plus nécessaires :
  notification-daemon libdbusmenu-glib1 libnotify1 libgee2 libindicate4
Veuillez utiliser « apt-get autoremove » pour les supprimer.
Les paquets suivants seront ENLEVÉS :
  pino
0 mis à jour, 0 nouvellement installés, 1 à enlever et 219 non mis à jour.
Après cette opération, 1225 kB d'espace disque seront libérés.
Souhaitez-vous continuer [O/n] ? 
[...]
$ sudo apt-get autoremove
[...]
Les paquets suivants seront ENLEVÉS :
  libdbusmenu-glib1 libgee2 libindicate4 libnotify1 notification-daemon
0 mis à jour, 0 nouvellement installés, 5 à enlever et 219 non mis à jour.
Après cette opération, 1307 kB d'espace disque seront libérés.
Souhaitez-vous continuer [O/n] ? 
[...]

synaptic, enfin, dispose dans ce but d’une nouvelle section accessible via le bouton « État » situé en bas à gauche : « Installés (pouvant être supprimés) ».

C’est une bonne habitude à prendre que de supprimer, à intervalle régulier, de tels paquets.

Drapeau d’installation automatique et réduction de la taille de votre système

Bien qu’APT positionne le drapeau « installé automatiquement » par lui-même, vous pouvez également le forcer manuellement. C’est une manière très simple de dire au système : « je n’ai pas particulièrement besoin de ce paquet, tu peux le désinstaller lorsque plus aucun autre n’en a besoin ».

# Avec apt-get
$ sudo apt-mark markauto libxml-simple-perl
# Ou avec aptitude
$ sudo aptitude markauto libxml-simple-perl

aptitude le permet également via son interface ncurses, grâce à la touche « M », pour marquer comme automatiquement installé le paquet sélectionné (et « m » pour enlever cet attribut). En ce qui concerne synaptic, il faut passer par le menu « Paquet > installé automatiquement ».

Un nombre important d’utilisateurs souhaiterait disposer d’une base installée minimale, tout en ne sachant pas réellement quels sont les paquets vraiment importants. Et la méthode consistant à « désinstaller le paquet et voir ce qui se passe » n’est pas une option très pratique…

Cette fonctionnalité permet donc, sans retirer (immédiatement) le paquet, de laisser le système décider, selon qu’il soit encore requis comme dépendance d’autres paquets ou non, s’il doit être désinstallé. Cette méthode comporte très peu de risques lorsqu’on l’applique aux bibliothèques (y compris les modules Python ou Perl).

Mon conseil serait de ne pas marquer comme « installés automatiquement » les paquets ayant une priorité supérieure ou égale à « important », ce afin d’éviter les surprises désagréables. Ceci étant, je dis cela uniquement pour me dédouaner d’éventuels problèmes créés parce que vous avez supprimé trop de paquets par ce biais. Car le système — en théorie — ne devrait pas supprimer ses constituants essentiels, le jeu des dépendances étant supposé être correctement et complètement renseigné.

Gardez également à l’esprit la conséquence du marquage d’un paquet tel que « gnome » : le système vous suggérera de supprimer entièrement votre bureau. Si tel est votre souhait, vous devriez alors dé-marquer les quelques paquets que vous souhaitez garder :

$ sudo apt-mark unmarkauto gnome-session gnome-panel

Ceci est une traduction de mon article Debian Cleanup Tip #6: Remove automatically installed packages that are no longer needed 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.