Développement C sous Linux - Empaquetage pour Debian et Fedora - XI.

Introduction

Vous êtes déjà au courant du langage de programmation C. Vous y avez pris goût et vous avez eu envie d’aller plus loin et d’écrire le vôtre. Ou peut-être aider la communauté et empaqueter votre logiciel préféré pour la distribution que vous aimez et utilisez. Quoi qu’il en soit, cette partie de la série de développement C vous montrera comment créer des paquets pour deux des distributions les plus populaires, Debian et Fedora. Si vous avez lu nos articles jusqu’à présent et que vous avez une solide connaissance de la ligne de commande, et que vous pouvez dire que vous connaissez la distribution de votre choix, vous êtes prêt.

Avant d’aller plus loin...

Mettons de côté quelques concepts et idées générales, juste pour nous assurer que nous sommes sur la même longueur d’onde. Ce que nous allons décrire ici est disponible quel que soit le projet pour lequel vous décidez d’empaqueter (ou de contribuer), que ce soit Arch, NetBSD ou OpenSolaris. L’idée est : soyez prudent. Vérifiez le code, qu’il s’agisse du vôtre ou non, et assurez-vous de vous rappeler que peut-être beaucoup de gens utiliseront votre code. Vous avez une responsabilité entre vos mains, et une très grande responsabilité. Si vous en doutez, inversez les lieux une seconde : un mainteneur de paquet ne fait pas attention lors de l’inspection du code et un bug sournois, mais grave, fait son chemin installé sur votre ordinateur. C’est sournois, car cela ne se manifeste que sur certains matériels et dans certaines situations, mais c’est suffisamment grave pour supprimer tous les fichiers résidant dans votre dossier personnel. Il se trouve que vous avez exactement cette combinaison de matériel et que le chaos s’ensuit, car vous avez oublié d’écrire sur DVD ces photos de vos vacances. Vous vous mettez en colère, votre première réaction est de manifester un sentiment négatif envers le système d’exploitation (ou la distribution) et donc, suite à votre décision de changer immédiatement de distribution, cette distribution perd un utilisateur, tout cela à cause du manque d’attention et de minutie d’une personne.

Debian

Étant donné l’excellente documentation de Debian, nous ne serons pas en mesure de couvrir tout ce dont on a besoin pour devenir développeur. Après tout, ce n’est pas ce que nous voulions. Ce que nous voulions, c’est vous montrer comment passer d’une archive de goudron à une .deb. Devenir un développeur Debian prend beaucoup de temps et implique que vous aidiez la communauté via IRC ou des listes de diffusion, que vous rapportiez et aidiez à corriger des bogues, etc., donc ce n’est pas l’objet de notre article. Jetez un coup d’œil à la documentation fournie par le projet pour plus d’informations. La politique Debian, le guide du nouveau responsable et la référence du développeur sont plus qu’importants pour démarrer, ils doivent être comme une sorte de livre avec lequel on dort sous l’oreiller.

Votre première étape devrait être, comme indiqué ci-dessus, la politique, où vous DEVEZ vous familiariser avec la hiérarchie du système de fichiers, les archives, les champs d’un fichier de contrôle et les éléments spécifiques à retenir concernant les différentes catégories de logiciels : binaires, bibliothèques, sources, jeux, documentation, ... N’oubliez pas qu’un fichier .deb n’est rien de plus qu’une archive, et qu’il est composé de deux parties : la partie contrôle, avec le fichier de contrôle et les scripts d’installation/désinstallation, et la charge utile, où résident les fichiers à installer. Ce n’est pas aussi difficile qu’on pourrait le penser. C’est une très bonne idée de télécharger un fichier .deb, encore mieux s’il contient un logiciel que vous connaissez bien, et de commencer à regarder à l’intérieur pour voir ce qu’il en est. [INDICE] – Vous pouvez utiliser le fichier de contrôle pour créer le vôtre, à condition de faire attention. À titre d’exemple, prenons vim. Les fichiers deb ne sont rien d’autre que des archives ar(1), ils peuvent donc simplement être décompressés en utilisant la commande linux suivante :

 $ ar vx vim-nox_7.3.547-5_amd64.deb

Bien sûr, v signifie verbeux et x signifie extrait. Après cette opération, nous verrons trois fichiers : control.tar.gz, data.tar.xz et un petit fichier texte appelé debian-binary, qui n’est rien de plus qu’un fichier indiquant à dpkg, le gestionnaire de paquets Debian, quel format binaire est utilisé. Mais cela n’a aucun intérêt pour l’instant. Pas plus que l’archive de données, qui se compose des fichiers qui doivent être décompressés sur votre système : le binaire, les pages de manuel, les bibliothèques, etc., selon le logiciel dont nous parlons. L’archive de contrôle est de la plus haute importance à cet égard. Si vous le décompressez, vous verrez le fichier essentiel, nommé control, les md5sums des fichiers à installer, et deux scripts, l’un qui s’occupe des problèmes de post-installation, et l’autre qui s’occupe de la pré-suppression. Puisque nous avons eu l’exemple d’un logiciel, prenons-le et voyons à quoi ressemblerait le fichier de contrôle. C’est à vous de décider, cher lecteur, si vous avez besoin de ces deux scripts et si oui, comment ils doivent être modifiés. Voici donc un fichier de contrôle, tiré de vim-nox et modifié pour yest.

Package: yest
Source: yest
Version: 2.7.0.5
Architecture: amd64
Maintainer: Rares Aioanei 
Installed-Size: 40355
Depends: libc6 (>= 2.11)
Suggests: 
Provides: yest
Section: other
Priority: normal
Homepage: sourceforge.net/projects/yest
Description: This is a command line date/time manipulation and formatting program, very useful in scripts. You can easily add or subtract days, hours and/or minutes
 from a specified date. Supports all date(1) output formats plus more.

Voilà, les amis. Pensez-vous qu’il y a autre chose dont vous avez besoin pour créer un package ? Vérifiez si tous vos fichiers sont en place, vous pouvez alors utiliser une méthode plus ancienne, d’autant plus que le logiciel est petit, simple et peu excentrique, si de tels mots existent.

 $ dpkg -b yestdir yest.deb

Maintenant, beaucoup de gens me diront, et je ne peux pas attendre, bien sûr, que c’est une vieille méthode de faire les choses et ainsi de suite. Et ils ont raison. Je vous suggère de parcourir la page de manuel de dpkg-buildpackage, ainsi que lintian pour vérifier la qualité de votre .deb, et n’oubliez pas de le faire avant de commencer quoi que ce soit, afin de vous assurer que tout est installé :

 # apt-get install build-essential autoconf automake autotools-dev dh-make debhelper devscripts fakeroot xutils lintian pbuilder

Chapeau mou

À mon avis, Fedora/Red Hat permet aux gens d’empaqueter plus facilement pour eux par rapport à Debian et ses dérivés. Cela étant dit, plus facile ne signifie pas toujours mieux, du moins dans le monde de l’informatique. Vous serez en mesure de vous faire un avis éclairé après cet article, nous l’espérons.

Encore une fois, assurez-vous que tous les outils sont installés, ce qui peut être fait en tapant ceci :

 # yum install @development-tools fedora-packager

Créez maintenant un utilisateur nommé makerpm, assurez-vous qu’il est dans le groupe mock et attribuez-lui un mot de passe :

 # useradd -m -G mock makerpm && passwd makerpm

Connectez-vous en tant qu’utilisateur et lancez la commande

 $ rpmdev-setuptree

dans le répertoire de base. Vous verrez, après la sortie de la commande, une nouvelle structure de répertoires nommée rpmbuild. Prenez le temps de l’examiner et de déterminer les objectifs de chaque répertoire et fichier. Maintenant, tout comme Debian utilise des fichiers de contrôle, Fedora utilise des fichiers spec. Ils sont appelés ainsi parce qu’ils ont l’extension .spec, de sorte que l’utilisateur sait qu’il spécifie les paramètres de construction du paquet : version, nom, auteur, mainteneur, dépends, etc. Quoi qu’il en soit, je m’avance. Commençons comme nous l’avons fait auparavant et téléchargeons un paquet source (encore une fois vim, pour plus de cohérence) pour voir où se trouve où. Pour cela, il faut installer le paquet yum-utils, qui offre yumdownloader :

 $ yumdownloader --source vim-enhanced

Maintenant, pour installer dans ~/rpmbuild, nous tapons

 $ rpm -ivh vim-enhanced[...].src.rpm

N’oubliez pas qu’un fichier RPM est une archive, tout comme .deb fichiers. La différence réside dans le format : alors que Debian utilise ar, Fedora/RH utilise cpio comme format de choix. Sachant cela, quelle serait la méthode à utiliser pour décompresser manuellement les .rpms ?

Vous avez peut-être remarqué qu’il existe un répertoire nommé SPECS dans votre ~/rpmbuild. cd et créez un fichier à l’aide de VIM ou Emacs, un fichier nommé yest.spec. Vous serez agréablement surpris de constater que ces deux éditeurs sont modifiés par Fedora de telle manière qu’ils vous offrent un « squelette » d’un fichier spec (tant que le fichier que vous souhaitez créer a l’extension .spec), vous pouvez donc simplement remplir les blancs. Maintenant, votre mission est, sur la base du fichier de contrôle ci-dessus et de vos connaissances jusqu’à présent, d’écrire un fichier de spécification complet pour yest et, bien sûr, de créer un RPM à partir de celui-ci. Le wiki de Fedora a une explication détaillée sur chaque section d’un fichier de spécification, veuillez la lire. Nous ne vous aiderons qu’avec la construction et la vérification du colis. En bref, utilisez yest.spec comme argument à rpmlint pour vérifier la conformité du fichier avec les directives d’empaquetage de Fedora, puis, lorsque tout s’avère être en ordre, et après avoir lu le manuel de rpmbuild, faites quelque chose comme ceci :

 $ rpmbuild -ba yest.spec

Les options données à rpmbuild signifient « build all », mais vous pouvez également compiler uniquement le paquet source, en utilisant -bs. N’oubliez pas que Mock et Koji sont deux outils très utiles, et rappelez-vous également que rpmlint est votre ticket pour des fichiers de spécifications de qualité.

Conclusion

Une chose à retenir est que, que vous ayez créé le logiciel que vous empaquetez ou non, la maintenance est très importante, parfois même plus importante que l’acte de création lui-même. Assurez-vous donc de savoir quelle responsabilité vous prenez sur vous-même : si vous n’êtes pas prêt à donner du temps, il vaut mieux que vous ne commenciez pas du tout, ou que vous vous assuriez de pouvoir donner le forfait à quelqu’un d’autre pour qu’il l’entretienne. Nous espérons que vous avez apprécié notre petite visite guidée de l’empaquetage Linux.

Tous les articles de cette série :