Dans l’article
précédent, nous avions vu comment préparer un dépôt debian viable de façon a faire des installation et des déploiements sur une plateforme debian [3].
Nous allons nous intéresser dans ce présent article sur comment alimenter notre dépôt et donc comment nous allons procéder pour construire un paquet debian.
Structure du paquet debian
Un paquet debian [4] n’est initialement qu’un tar.gz dont l'extension est .deb, construit à l’aide de la commande dpkg-deb (il existe d’autre approche comme jdeb [5]) qui sera déployé à la racine /. Cela signifie qu’il sera nécessaire lors de la conception du paquet de reproduire l’arborescence cible si l’on souhaite déployer des fichiers dans des répertoires précis du système.
Ainsi par exemple si l’on souhaite construire un paquet permettant de déployer un binaire dans le système, on créera un répertoire du nom du paquet dans lequel on trouvera le chemin /usr/bin/monBinaire:
/home/moi/monPaquet/usr/bin/monBinaire
Ainsi quand l’on construira le paquet, celui ci déposera monBinaire dans /usr/bin.
Cette démarche est valable pour tout fichier déposé statiquement dans le système. A noter que lors de cette étape, dpkg, le composant procédant à l’installation, fait le listing des fichiers déposés et défini le paquet (et ses éventuelles versions futur) comme responsable du cycle de vie du fichier dans le système. Ceci a pour intérêt de détecter lors de l’installation d'éventuels conflit entre paquet qui seront à traiter par des primitives particulières quand cela est possible [2] (ce ne sera pas le cas dans cet article). Pour que dpkg puisse clairement identifier le paquet, celui ci doit obligatoirement contenir un fichier de control contenant toutes les informations sur l’identité, la version, l’utilisation du paquet. Vous verrons plus loin dans l’article ou le déposer et comment le construire
Par contre si nous avons ici un moyen simple et efficace pour déployer des fichiers, nous n’avons rien pour dynamiquement configurer l’installation en fonction du système courant.
En effet, souvent, lors de l’installation, il est nécessaire de prendre en considération au mieux des besoins et de l’environnement en initialisant des fichiers de conf selon les autres applications présentes, le contexte réseau éventuel ou même des préférences utilisateurs.
La première approche est alors d’apporter statiquement des configurations par défaut et de les modifier après l’installation. Cette approche fonctionne si et seulement si l'application ne nécessite pas une synchronisation particulière avec d’autres applications du système qui nécessite un redémarrage (par exemple la prise en compte d’un plugin par une application amené par deux paquets différents qu’il faut nécessairement redémarrer)
Les fichiers du responsable
Pour répondre à ce problème spécifique, en plus du fichier de
control (obligatoire) et il est possible de définir des fichiers du responsable (
postinst, preinst, postrm et prerm). Ces fichiers sont à placer dans un répertoire DEBIAN de notre paquet. Notre paquet devient alors:
(/home/moi) ./monPaquet/usr/bin/monBinaire(/home/moi) ./monPaquet/DEBIAN/control (obligatoire)(/home/moi) ./monPaquet/DEBIAN/postinst (optionnel)(/home/moi) ./monPaquet/DEBIAN/preinst (optionnel)(/home/moi) ./monPaquet/DEBIAN/postrm (optionnel)(/home/moi) ./monPaquet/DEBIAN/prerm (optionnel)
Ces fichiers sont alors exécuter automatiquement par l’outil dpkg [6] pendant l’installation ou la suppression.
Par exemple la phase d’installation exécute les phases suivantes:
De la même façon la suppression d’un paquet exécute les fichiers du responsables comme suit:
Enfin leur combinaison permet d’obtenir le comportement que l’on aura lors d’une mise à jour:
A noter que les scripts peuvent être des simples fichiers qui s'exécutent indifféremment du contexte (pas de la phase) mais qu’il est possible de leur attribuer des spécificités selon que l’on fait justement par exemple une installation ou une mise a jour. Pour cela il est conseillé de s’appuyer sur un squelette de script par défaut ou skeleton [7] (que je ne détaillerai pas ici).
Le fichier de control
Voila maintenant que l’on a construit la structure du deb, il reste finaliser le debian en définissant dans le détail le fichier de control.
Le fichier de control est comme dit sommairement au début de cet article, la pièce d’identitée du paquet debian a construire.
Il se constitue des champs suivant [8] (directement extrait de la documentation):
Package: hello
Version: 2.9-2+deb8u1
Architecture: amd64
Maintainer: Santiago Vila <sanvila@debian.org>
Depends: libc6 (>= 2.14)
Conflicts: hello-traditional
Breaks: hello-debhelper (<< 2.9)
Replaces: hello-debhelper (<< 2.9), hello-traditional
Section: devel
Priority: optional
Homepage: http://www.gnu.org/software/hello/
Description: example package based on GNU hello
The GNU hello program produces a familiar, friendly greeting. It
allows non-programmers to use a classic computer science tool which
would otherwise be unavailable to them.
.
Seriously, though: this is an example of how to do a Debian package.
It is the Debian version of the GNU Project's `hello world' program
(which is itself an example for the GNU Project).
- Le champ « Package » contient le nom du paquet. C'est le nom par lequel les outils de gestion de paquets peuvent le manipuler. Il est habituellement similaire mais pas nécessairement le même que la première chaîne composant le nom de l'archive Debian.
- Le champ de « Version » donne le numéro de version du composant.
- Le champ « Architecture » indique pour quel processeur ce binaire particulier a été compilé.
- Le champ « Depends » donne une liste des paquets qui doivent être installés afin d'installer ce paquet avec succès.
- La ligne « Section » indique la section où le paquet Debian est conservé sur les sites FTP de Debian.
- Le champ « Maintainer » contient l'adresse électronique de la personne actuellement responsable de la maintenance du paquet.
- Le champ « Description » fournit un bref résumé des fonctionnalités du paquet.
Bien sur tous ces champs suivant une nomenclature et de standards pour permettre de normaliser l’utilisation des paquets. Entre autre par exemple il est important de respecter certaines règles d'écriture du numéro de version afin de permettre des mises à jours conforme a l’attendu (voir les schémas du chapitre des fichiers du responsable sur les phases du cycle de vie d’installation, désinstallation et de mise à jour des paquets).
Chaque champs peut avoir son importance même s’ils ne sont pas obligatoire. Il convient donc de bien les étudier afin de prévenir ou de gérer les conflits entre paquets.
Construction du paquet debian
Pour finir cet article, il fait maintenant finaliser le packaging en construisant le .deb. Pour cela il suffit d’appeler la commande dpkg-deb:
dpkg-deb --build $REPERTOIRE_DEBIAN $REPO_DEBIAN/
avec REPERTOIRE_DEBIAN contenant le chemin du debian a packager et REPO_DEBIAN le répertoire de destination ou mettre le deb final (on privilégiera directement le dépôt debian)
Voila le paquet est construit et déposé dans un dépôt, il ne reste qu'à l’installer après une mise a jour du dépôt et un apt-get coté client.
Références
[1] http://blog.valouille.fr/2013/10/creer-un-paquet-debian-vide/
[2] https://www.debian.org/doc/manuals/debian-handbook/sect.package-meta-information.fr.html
[3] https://www.debian.org/doc/manuals/debian-faq/index.fr.html#contents
[4] https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.fr.html
[5] http://tcurdt.github.io/jdeb/
[6] https://www.debian.org/doc/debian-policy/#maintainer-script-flowcharts
[7] https://lists.debian.org/debian-mentors/1998/04/msg00004.html
[8] https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.fr.html#s-controlfile
