Savoir recompiler un paquet Debian existant est particulièrement utile. En effet, il s’agit là d’un prérequis indispensable à certaines tâches qu’un administrateur peut vouloir effectuer : activer une fonctionnalité désactivée dans le paquet Debian officiel, recompiler les sources pour un autre environnement (récupérer la version correspondant à Debian testing pour faire fonctionner le paquet sous Debian stable par exemple — ce qui, d’ailleurs, est le principe même des applications disponibles dans les backports), inclure une correction que les développeurs upstream ont mise à disposition, … Cet article vous propose de découvrir les 4 étapes nécessaires à cette recompilation :
1. Télécharger les sources
La « meilleure » manière de télécharger les sources reste l’utilisation d’APT. Il permet de les télécharger depuis les dépôts source paramétrés dans le fichier /etc/apt/sources.list, comme par exemple :
deb-src http://ftp.debian.org/debian unstable main contrib non-free deb-src http://ftp.debian.org/debian testing main contrib non-free deb-src http://ftp.debian.org/debian stable main contrib non-free
Comme on le voit, le premier mot-clé indique clairement à APT que l’on s’intéresse aux sources, et non pas aux binaires.
Si les dépôts source n’étaient pas présents dans le fichier auparavant, un petit apt-get update permettra de mettre à jour la base et vous pourrez récupérer par exemple la dernière version des sources du paquet publican, via la commande apt-get source publican. Il est également possible d’indiquer la distribution au sein de laquelle il faut récupérer les sources, avec la syntaxe « package/distribution« . Dans notre cas, apt-get source publican/testing récupérera les sources de publican à partir du dépôt testing et les extraira dans le répertoire courant (via la commande dpkg-source -x, avec comme prérequis le paquet dpkg-dev installé).
$ apt-get source publican/testing Lecture des listes de paquets... Fait Construction de l'arbre des dépendances Lecture des informations d'état... Fait Note : la maintenance du paquet de « publican » est réalisée dans le système de suivi de versions « Git » à l'adresse : git://git.debian.org/collab-maint/publican.git Nécessité de prendre 888 ko dans les sources. Réception de : 1 http://ftp.fr.debian.org/debian/ testing/main publican 2.5-2 (dsc) [2 292 B] Réception de : 2 http://ftp.fr.debian.org/debian/ testing/main publican 2.5-2 (tar) [879 kB] Réception de : 3 http://ftp.fr.debian.org/debian/ testing/main publican 2.5-2 (diff) [6907 B] 888 ko réceptionnés en 8s (104 ko/s) dpkg-source: info: extraction de publican dans publican-2.5 dpkg-source: info: extraction de publican_2.5.orig.tar.gz dpkg-source: info: extraction de publican_2.5-2.debian.tar.gz dpkg-source: info: mise en place de perl-critic-fixes-svn1732 $ ls -dF publican* publican-2.5/ publican_2.5-2.debian.tar.gz publican_2.5-2.dsc publican_2.5.orig.tar.gz
Si vous ne souhaitez pas utiliser APT, ou si le paquet source n’est pas hébergé par un dépôt APT, il est toujours possible de télécharger le paquet source complet via dget -u dsc-url, où dsc-url représente l’URL du fichier .dsc, image des sources du paquet. L’utilitaire dget est fourni par le paquet devscripts. L’option -u mérite d’être retenue : elle signifie que l’origine des sources ne sera pas vérifiée avant extraction.
2. Installer les dépendances de compilation
Là-aussi, APT peut faire le boulot ingrat à votre place. Tout ce que vous avez à faire est de lancer apt-get build-dep mon-paquet afin que les dépendances nécessaires à la compilation de mon-paquet soient installées. La syntaxe restant la même que pour apt-get source, il est possible de lancer apt-get build-dep publican/testing, ce qui aura pour effet d’installer les dépendances pour la compilation de la version testing de publican.
Si vous ne pouvez pas utiliser APT pour faire cela, placez-vous directement dans le répertoire contenant l’extraction du paquet source et lancez dpkg-checkbuilddeps. En sortie, vous aurez une liste de dépendances de compilation non satisfaites (dans le cas contraire, la commande restera muette, et vous pourrez continuer tranquillement). Dans ce cas, un enchaînement de copier/coller et d’apt-get install permettra de remédier au problème en quelques secondes.
3. Faites les modifications requises
Je ne détaillerai pas cette étape, dans la mesure où elle dépend totalement des objectifs particuliers qui vous poussent à recompiler. Vous serez peut-être amené à modifier le fichier debian/rules, ou à appliquer un patch.
Dans tous les cas, une chose est sûre : si vous avez changé quoi que ce soit, ou recompilé le paquet dans un environnement différent, vous devriez vraiment changer son numéro de version. dch --local perso (toujours du paquet devscripts) vous permet de le faire simplement : remplacer simplement perso par un nom court vous identifiant comme le pourvoyeur de cette version. debian/changelog sera modifié en conséquence et vous serez invité à documenter brièvement les changements opérés.
4. Compiler le paquet
La dernière étape est également la plus simple, maintenant que tout est en place. Vous devez vous placer à la racine du répertoire où sont extraites les sources, et lancer debuild -us -uc (procédure recommandée, nécessite le paquet devscripts), ou directement dpkg-buildpackage -us -uc. Les options « -us -uc » évitent l’étape de la signature qui provoquerait une erreur (bénigne) à la fin si vous ne disposez pas de clé GPG correspondant au nom entré au début du fichier des modifications Debian (debian/changelog).
$ cd publican-2.5 $ debuild -us -uc dpkg-buildpackage: export de CFLAGS depuis dpkg-buildflags (origine : vendor): -g -O2 dpkg-buildpackage: export de CPPFLAGS depuis dpkg-buildflags (origine : vendor): dpkg-buildpackage: export de CXXFLAGS depuis dpkg-buildflags (origine : vendor): -g -O2 dpkg-buildpackage: export de FFLAGS depuis dpkg-buildflags (origine : vendor): -g -O2 dpkg-buildpackage: export de LDFLAGS depuis dpkg-buildflags (origine : vendor): dpkg-buildpackage: paquet source publican dpkg-buildpackage: version source 2.5-2 dpkg-buildpackage: source changé par Raphaël Hertzog dpkg-buildpackage: architecture hôte amd64 [...] dpkg-deb: compilation du paquet `publican' en `../publican_2.5-2rh1_all.deb'. dpkg-genchanges >../publican_2.5-2rh1_amd64.changes dpkg-genchanges: sources originales non incluses en version amont dpkg-source --after-build publican-2.5 dpkg-buildpackage: binary and diff upload (sources originales NON incluses) Lancement de lintian... lintian : terminé.
La compilation est terminée. Les sources mises à jour ainsi que les paquets binaires ont été générés dans le dossier parent.
$ cd .. $ ls -dF publican* publican-2.5/ publican_2.5-2rh1.dsc publican_2.5-2.debian.tar.gz publican_2.5-2rh1_amd64.changes publican_2.5-2.dsc publican_2.5-2rh1_source.changes publican_2.5-2rh1_all.deb publican_2.5.orig.tar.gz publican_2.5-2rh1.debian.tar.gz
Cet article est une traduction de Howto to rebuild Debian 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.
Merci bien pour ce récap’, avec les petites astuces glissées ça et là entre deux commandes 🙂
En tant que newbie de la compilation, grâce à ton bouquin (qui pour moi date de Sarge) et quelques infos glanées sur le Web, j’arrive à recompiler quand il n’y a pas trop d’embuches mais à la vue de cet article, je mérite d’essayer un peu plus les utilitaires de « devscripts ».
Ma dernière tentative, s’est soldé par un échec… je voulais récupérer des sources sur mentors, mais APT n’arrive pas à les récupérer car il tente de récupérer le fichier « Sources » alors que celui dispo sur le dépôt est « Sources.gz ». Il est bien compliqué de gérer les Build-Dep sans l’aide d’APT.
Il me semble que j’ai déjà eu ce problème, impossible de me rappeler d’une solution. Une idée ?
Avec une ligne comme ci-dessous dans mon sources.list, cela fonctionne:
Il faut par contre préciser la version exacte sinon apt-get source semble essayer de récupérer une autre version que celle disponible sur mentors… par exemple « apt-get source zathura=0.0.8.4-1 ».
Grrr… il me manquait le répertoire
dans l’URL ! Cela m’est déjà arrivé, même avec d’autres dépôts. Rien à voir avec le fait qu’APT essaie de récupérer un ficher gzip ou non, il gère cela de manière transparente…
ce qui serait bien c’est que tu fabriques l’outil qui génère le document .dsc
avec écrit dedans toutes les -dev de constructions nécéssaires
Je ne comprends pas ce que tu me demandes… les fichiers .dsc existent déjà, c’est les fichiers de référence des paquets source.
parce que quand je compile un tarball source avec dpkg-buildpackage il y a bien les librairies d’utilisations qui sont écrites dans le document control mais pas toutes les librairies Build-Depends de compilation pour le document .dsc
c’est un peu expliqué là:
http://www.debian.org/doc/manuals/developers-reference/tools.html#dpkg-depcheck
dpkg-depcheck (du paquet devscripts, devscripts) exécute une commande sous strace pour déterminer tous les paquets utilisés par la commande.
Pour les paquets Debian, c’est utile pour créer une ligne Build-Depends d’un nouveau paquet : exécuter le processus de compilation avec dpkg-depcheck fournira une bonne première approximation des dépendances de compilation. Par exemple :
dpkg-depcheck -b debian/rules build
dpkg-depcheck peut aussi être utilisé pour vérifier les dépendances d’exécution, d’autant plus si le paquet utilise exec(2) pour exécuter d’autres programme
il est écrit:approximation des dépendances
à noter= ton « exprimez vous! » est très très lent à réagir en écriture
Ok, je comprends mieux, malheureusement il est quasiment impossible de détecter les toutes les dépendances de construction automatiquement. C’est au mainteneur de les saisir dans le champs Build-Depends de debian/control et tu connais déjà un des outils qui peut aider à définir les paquets à lister. L’autre alternative étant de rajouter les paquets nécessaires au fur et à mesure des échecs de compilation avec un outil comme pbuilder.
c’est bien ce que je pensais merci pour cette confirmation