Chapitre 15. Conception d'un paquet Debian

Manipuler régulièrement des paquets Debian provoque tôt ou tard le besoin de créer le sien ou d'en modifier un. Ce chapitre essaie de répondre à vos interrogations en la matière et fournit des éléments pour tirer le meilleur parti de l'infrastructure offerte par Debian. Qui sait, en ayant ainsi mis la main à la pâte, peut-être irez-vous plus loin et deviendrez-vous développeur Debian !

15.1. Recompiler un paquet depuis ses sources

Plusieurs éléments justifient la recompilation d'un paquet depuis ses sources. L'administrateur peut avoir besoin d'une fonctionnalité du logiciel qui implique de recompiler le programme en activant une option particulière ou souhaiter en installer une version plus récente que celle fournie dans sa version de Debian (dans ce cas, il recompilera un paquet plus récent récupéré dans la version Testing ou Unstable pour qu'il fonctionne parfaitement dans sa distribution Stable, opération appelée le rétroportage). On prendra soin de vérifier, avant de se lancer dans une recompilation, que personne d'autre ne s'en est déjà chargé ; on pourra vérifier en particulier sur la page dédiée du système de suivi de paquets.

→ https://tracker.debian.org/

15.1.1. Récupérer les sources

La reconstruction d'un paquet Debian commence par l'obtention de son code source. Le moyen le plus simple est d'utiliser la commande apt-get source nom_du_paquet. Cette commande nécessite une ligne deb-src dans le fichier /etc/apt/sources.list et des fichiers d'index à jour (c'est-à-dire apt-get update). Ces conditions devraient déjà être remplies si vous avez suivi les instructions du chapitre traitant de la configuration d'APT (voir la Section 6.1, « Renseigner le fichier sources.list »). Notez cependant que vous téléchargerez les paquets source de la version de Debian mentionnée dans la ligne deb-src.

Si vous souhaitez une version particulière, il vous faudra peut-être la télécharger manuellement depuis un miroir Debian ou depuis le site web. Cela implique de récupérer deux ou trois fichiers (d'extensions *.dsc — pour Debian Source Control — *.tar.comp et parfois *.diff.gz ou *.debian.tar.comp — comp pouvant prendre les valeurs gz, bz2 ou xz selon l'outil de compression employé), puis d’exécuter la commande dpkg-source -x fichier.dsc. Si le fichier *.dsc est disponible à un URL donné, on pourra même se simplifier la vie en utilisant dget URL. Cette commande (qui fait partie du paquet devscripts) récupère le fichier *.dsc à l'adresse indiquée, en analyse le contenu et récupère automatiquement le ou les fichiers qu'il référence. Après le téléchargement des fichiers, il vérifie l’intégrité des paquets en utilisant dscverify et extrait le paquet source (à moins que l'option -d ou --download-only soit spécifiée). Le trousseau de clés de Debian est nécessaire à moins que l’option -u soit indiquée.

15.1.2. Effectuer les modifications

Prenons le paquet samba pour exemple.

$ apt source samba
Reading package lists... Done
NOTICE: 'samba' packaging is maintained in the 'Git' version control system at:
https://salsa.debian.org/samba-team/samba.git
Please use:
git clone https://salsa.debian.org/samba-team/samba.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 12.3 MB of source archives.
Get:1 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (dsc) [4,514 B]
Get:2 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (tar) [11.8 MB]
Get:3 http://security.debian.org/debian-security bullseye-security/main samba 2:4.13.13+dfsg-1~deb11u3 (diff) [468 kB]
Fetched 12.3 MB in 3s (4,582 kB/s)
dpkg-source: info: extracting samba in samba-4.13.13+dfsg
dpkg-source: info: unpacking samba_4.13.13+dfsg.orig.tar.xz
dpkg-source: info: unpacking samba_4.13.13+dfsg-1~deb11u3.debian.tar.xz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 07_private_lib
dpkg-source: info: applying bug_221618_precise-64bit-prototype.patch
dpkg-source: info: applying [...]

Le source du paquet est maintenant disponible dans un répertoire portant le nom du paquet source et sa version (samba-4.13.13+dfsg), nous pouvons nous y rendre pour y effectuer nos modifications.

La première modification à apporter est de changer le numéro de version du paquet pour distinguer les paquets recompilés des originaux fournis par Debian. Supposons que la version actuelle soit 2:4.13.13+dfsg-1~deb11u3 ; nous pouvons créer une version 2:4.13.13+dfsg-1~deb11u3+falcot1, ce qui désigne clairement l'origine du paquet. De cette manière, la version est supérieure à celle fournie par Debian et le paquet s'installera facilement en tant que mise à jour de l'original. Pour effectuer ce changement, il est préférable d'utiliser le programme dch (Debian CHangelog) du paquet devscripts.

$ cd 4.13.13+dfsg-1~deb11u3
$ dch --local +falcot

La dernière commande appelle un éditeur de texte (sensible-editor — il doit s’agir de votre éditeur favori s’il est mentionné dans les variables d’environnement VISUAL ou EDITOR ou l’éditeur par défaut sinon) pour permettre de documenter les différences apportées par cette reconstruction. Cet éditeur montre que dch a vraiment changé le fichier debian/changelog.

When a change in build options is required, the changes need to be made in debian/rules, which drives the steps in the package build process. In the simplest cases, the lines concerning the initial configuration (./configure …) or the actual build ($(MAKE) … or make … or cmake … or …) are easy to spot. If these commands are not explicitly called, they are probably a side effect of another explicit command, in which case please refer to their documentation to learn more about how to change the default behavior. With packages using dh, you might need to add an override for the dh_auto_configure or dh_auto_build commands (see their respective manual pages and debhelper(7) for explanations on how to achieve this).

Il convient parfois de s'occuper du fichier debian/control, qui renferme la description des paquets générés. Il peut être intéressant de la modifier pour qu'elle reflète les changements apportés. Par ailleurs, ce fichier contient aussi des champs Build-Depends qui donnent la liste des dépendances de génération du paquet. Celles-ci se rapportent souvent à des versions de paquets contenus dans la distribution d'origine du paquet source, qui ne sont peut-être pas disponibles dans la version utilisée pour la recompilation. Il n'existe pas de moyen automatique pour savoir si une dépendance est réelle ou si elle a été créée pour garantir que la compilation s'effectue bien avec les dernières versions d'une bibliothèque (c'est le seul moyen disponible pour forcer un autobuilder à recompiler le paquet avec une version prédéfinie d'un paquet — c'est pourquoi les mainteneurs Debian utilisent fréquemment ce procédé).

N'hésitez donc pas à modifier ces dépendances pour les assouplir si vous savez qu'elles sont trop strictes. La lecture d'éventuels fichiers documentant le mode de compilation du logiciel (souvent nommés INSTALL) vous sera sans doute utile pour retrouver les bonnes dépendances. Idéalement, il faudrait satisfaire toutes les dépendances avec les paquets disponibles dans la version utilisée pour la recompilation. Sans cela, on entre dans un processus récursif où il faut préalablement rétroporter les paquets donnés dans les champs Build-Depends avant de pouvoir compléter le rétroportage souhaité. Certains paquets, qui n'ont pas besoin d'être rétroportés, seront installés tels quels pour les besoins de la recompilation (c'est souvent le cas de debhelper). Cependant, le processus peut se compliquer rapidement si l'on n'y prend garde, aussi faut-il éviter autant que possible tout rétroportage non strictement nécessaire.

15.1.3. Démarrer la recompilation

Toutes les modifications souhaitables étant apportées sur les sources, il faut maintenant régénérer le paquet binaire correspondant (fichier .deb). Tout ce processus de création est contrôlé par le programme dpkg-buildpackage.

Exemple 15.1. Recompilation d'un paquet

$ dpkg-buildpackage -us -uc
[...]

The previous command can fail if the Build-Depends field has not been updated, or if the related packages are not installed. In such a case, it is possible to overrule this check by passing the -d option to dpkg-buildpackage. However, explicitly ignoring these dependencies runs the risk of the build process failing at a later stage. Worse, the package may seem to build correctly but fail to run properly: some programs automatically disable some of their features when a required library is not available at build time. The switch can still be very useful if you only want to create a source package, which is supposed to be passed to clean build environments as described in QUICK LOOK Building packages in chrooted and virtual environments.

The other options used in the above example make sure that neither the source package's .dsc (-us) nor the produced .changes file (-uc) get signed with the package builder's cryptographic key after the asuccessful build.

OUTIL fakeroot

Le processus de création de paquet, qui finalement se contente de rassembler dans une archive des fichiers existant localement (ou compilés), a besoin de créer des fichiers dont le propriétaire sera le plus souvent root. Pour éviter de compiler les paquets sous l'identité de l'administrateur, ce qui induirait des risques inutiles, on peut utiliser l'utilitaire nommé fakeroot. Lorsqu'il est utilisé pour lancer un programme, fakeroot laisse croire à ce programme qu'il tourne sous l'identité de root, et que les fichiers qu'il crée appartiennent également à l'administrateur. Lorsque le programme va créer l'archive qui deviendra le paquet Debian, il pourra ainsi y placer des fichiers appartenant à divers propriétaires. C'est pourquoi dpkg-buildpackage utilise par défaut fakeroot pour la préparation des paquets.

Notez qu'il ne s'agit que d'une impression donnée au programme lancé et qu'on ne peut donc pas utiliser cet outil pour obtenir des privilèges quelconques. Le programme tourne réellement sous l'identité de l'utilisateur qui lance fakeroot programme et les fichiers qu'il crée réellement continuent de lui appartenir.

More often than not, Debian developers use a higher-level program such as debuild; this runs dpkg-buildpackage as usual, but it also adds an invocation of a program that runs many checks to validate the generated package against the Debian policy. This script also cleans up the environment so that local environment variables do not “pollute” the package build. The debuild command is one of the tools in the devscripts suite, which share some consistency and configuration to make the maintainers' task easier.

QUICK LOOK Building packages in chrooted and virtual environments

Building a package on an existing system, like a workstation or server, can pose several problems. Maybe the system has packages installed, that conflict with the build requirements. Or maybe it has packages (libraries, headers, etc.) installed, that the project to build is not supposed to use - e.g. from Testing, Unstable, or even from third parties. Also it might have packages installed, which are actually required for the build, but are not listed in debian/control. It is therefore a good practice to build a packages in “clean“ environments.

The sbuild, pbuilder, or cowbuilder programs (in the similarly named packages) allow building a Debian package in a chrooted environment. Each of them first creates a temporary directory containing the minimal system required for building the package (including the packages mentioned in the Build-Depends field). This directory is then used as the root directory (/), using the chroot command, during the build process.

These tools allow the build process to happen in an environment that is not altered by users' manipulations. This also allows for quick detection of the missing build-dependencies (since the build will fail unless the appropriate dependencies are documented). Finally, it allows building a package for a Debian version that is not the one used by the system as a whole: the machine can be using Stable for its normal workload, and the chrooted environments can be running on the same machine using Unstable for package builds. Using these tools, it is also possible to build for a different distribution, like Ubuntu.

schroot, sbuild-shell, or pbuilder allow running a command or a login shell in a chrooted environment.

Sometimes it is not enough to build a package in a chrooted environment. This can be due to building for a different architecture where cross-compilation does not work, or due to the tools not being able to create a chrooted environment for the desired target system. Then one can create virtual machines to build the package there. These setups are usually more complex then the tools mentioned above, and rarely needed, so we will only mention this possibility without going into much detail. Check out Section 12.2, « Virtualisation » for an introduction into this topic.