Différences

Ci-dessous, les différences entre deux révisions de la page.

--- projets:paquets:creer_un_paquet [Le 07/11/2006, 14:10]
teolemon orthographe
+++ — (Version actuelle)
@@ Ligne 1: / Ligne 1: @@
-  Version Dapper
-Initié par [[utilisateurs:Ju]] et rédigé par [[utilisateurs:lordphoenix]] suite à la séance de formation organisé par [[utilisateurs:Gloubiboulga]] sur le canal IRC #ubuntu-fr-classroom. Encore merci à lui pour cette initiative
-Avec les corrections de kagou, Sp4rky et Gloubiboulga
-Une [[projets:paquets:faq | Foire Aux Questions]] est disponible.
-====== Comment créer des paquets sous Ubuntu Linux ======
-===== Présentation =====
-Dans une version récente de Linux comme peut l'être Ubuntu, l'installation de logiciels est devenue extrêmement facile grâce à AptGet ou Synaptic qui donnent accès à des dépôts contenant pas loin de 18000 paquets. Pourtant la richesse de l'univers des logiciels libres  fait que malgré ce nombre important il existe encore des applications qui ne sont pas packagées. Nous allons donc nous intéresser ici à la création de paquet debian (les fameux fichiers .deb) à partir des sources d'une application existante.
-==== Pré requis ====
-Pour pouvoir suivre cette documentation un certain nombre de pré-requis sont nécessaires :
-  * Les dépôts source doivent être disponibles dans synaptic (décommentez les lignes qui commencent par deb-src dans /etc/apt/sources.list)
-  * Installez sur votre ordinateur les paquets suivants:
-    * debhelper
-    * cdbs
-    * lintian
-    * linda
-    * build-essential
-    * fakeroot
-    * devscripts
-    * pbuilder
-    * dh-make
-En une ligne :
-  sudo apt-get install debhelper cdbs lintian linda build-essential fakeroot devscripts pbuilder dh-make
-===== Étude du contenu d'un paquet debian source =====
-==== Paquet binaire et paquet source ====
-Commençons par une petite précision technique. Les paquets binaires sont les paquets (.deb) qui contiennent les fichiers nécessaires à l'application pour pouvoir fonctionner sur votre ordinateur. C'est ce que nous allons nous efforcer de créer. Tous les paquets binaires disponibles dans les dépôts Ubuntu ont été construits à partir de paquets sources. Un paquet source est un ensemble de fichiers (attention le terme de paquet est utilisé par analogie. Il n'y a pas ici de fichier conteneur comme peut l'être le .deb pour les binaires) contenant les sources originelles de l'application, ainsi que les indications des modifications nécessaires à la création du paquet debian.
-==== Étude d'un exemple de paquet source ====
-Pour illustrer cela nous allons examiner le contenu d'un paquet source. Pour cela il faut le télécharger d'un des dépôts source configuré pour apt.
-Commençons par créer le dossier dans lequel nous allons travailler.
-<code bash>
-mkdir ~/packaging && cd ~/packaging
-</code>
-Et téléchargeons un paquet source
-<code bash>
-apt-get source xfce4-xkb-plugin
-ls
-</code>
-la commande ls nous donne comme contenu :
-  * un répertoire xfce4-xkb-plugin-0.4.1
-  * et les fichiers suivants :
-    * xfce4-xkb-plugin_0.4.1.orig.tar.gz
-    * xfce4-xkb-plugin_0.4.1-0ubuntu5.dsc
-    * xfce4-xkb-plugin_0.4.1-0ubuntu5.diff.gz
-(note : vous obtiendrez exactement ces fichiers si vous êtes sous Dapper, peut-être une autre version sous Edgy)
-Le fichier **xfce4-xkb-plugin_0.4.1.orig.tar.gz** est en fait l'archive contenant les fichiers sources tels que l'on peut les obtenir sur le site du projet (typiquement ceux que l'on installe avec ./configure && make && make install). Le répertoire est d'ailleurs issue de la décompression, de cette archive. Seul le nom du fichier a été changé pour des raisons que nous préciserons plus tard.
-Le fichier **xfce4-xkb-plugin_0.4.1-0ubuntu5.dsc** contient la description du paquet source (et des deux autres fichiers, avec leur taille et leur somme md5).
-le fichier **xfce4-xkb-plugin_0.4.1-0ubuntu5.diff.gz** contient toutes les modifications nécessaires pour construire le paquet debian. Constituer un paquet source nécessite d'ajouter aux sources existantes un répertoire debian/ avec quelques fichiers. C'est ce répertoire que contient le fichier .diff.gz
-Maintenant que l'on a une idée de ce que sont les paquets sources, nous allons créer notre premier paquet.
-===== Création de notre premier paquet =====
-====Création du paquet source====
-Pour notre exemple nous allons construire le paquet de l'application epdfview, petite application de consultation de documents PDF.
-Après avoir supprimé le contenu de notre dossier ~/packaging pour repartir d'une situation propre, on télécharge les sources du dit logiciel.
-Donc dans ~/packaging :
-<code bash>
-rm -rf * # on nettoie :)
-mkdir epdfview && cd epdfview
-wget http://gauvain.tuxfamily.org/school/2006-08-31/epdfview-0.1.5.tar.gz
-</code>
-On utilise ici le site de Gloubiboulga en lieu et place du site officiel, car celui ci est particulièrement lent.
-Une fois les sources récupérées, la **première** chose à faire est de renommer le tarball, afin de pouvoir créer un paquet source correct par la suite. Attention le format de ce nom est important. Une erreur ici n'est pas particulièrement désastreuse, mais met en péril la qualité du paquet source. La syntaxe est //paquet_version.orig.tar.gz// (notez le '_' à la place du '-' d'origine).
-Il faut donc exécuter dans le terminal :
-<code bash>
-mv epdfview-0.1.5.tar.gz epdfview_0.1.5.orig.tar.gz
-</code>
-Notez le nom similaire au fichier correspondant que nous avons trouvé dans le chapitre précédent.
-Puis on décompresse cette archive :
-<code bash>
-tar zxvf epdfview_0.1.5.orig.tar.gz
-cd epdfview-0.1.5
-</code>
-Et on entre dans le répertoire contenant les sources.
-Une règle d'or dans la création de paquets est de **ne pas toucher au tarball d'origine**. La seule chose autorisée est de le renommer (c'est même nécessaire). Ne pas modifier le tarball permet de bien distinguer le travail de l'auteur de celui du packageur.
-Maintenant que les sources sont là, ainsi que le .orig.tar.gz, on va pouvoir créer le paquet. Pour cela il faut créer le dossier debian/ dans le dossier des sources (je vous rappelle que c'est ce dossier debian qui va donner les différents fichiers contenus dans notre paquet source (cf chap1)).
-Pour créer un squelette de dossier debian/, utilisez dh_make installé disponible dans le paquet dh-make (cf pré-requis).
-La commande
-<code bash>
-dh_make -e votreaddresse@email.tld
-</code>
-doit normalement vous retourner ceci :
-<code bash>
-Type of package: single binary, multiple binary, library, kernel module or cdbs?
-[s/m/l/k/b]
-</code>
-Qui vous permet de préciser quel type de package on construit. Ici choisissez le type de paquet "single", répondez donc *s* à la question.
-Pour les curieux quelques commentaires sur les autres choix :
-  * multiple binary permet de créer plusieurs paquets binaires à partir d'un unique paquet source
-  * library permet de créer une bibliothèque (lib quelque chose)
-  * kernel module... un module pour le noyau
-  * cdbs... on verra plus tard
-Attention il faut saisir cette commande dans le dossier contenant les sources. Dans notre cas :
->~/packaging/epdfview/epdfview-0.1.5
-<code bash>
-Hit <enter> to confirm :
-</code>
-On confirme avec la touche [Entrée].
-On doit maintenant avoir dans le dossier contenant les sources de notre application un dossier debian/.
-On entre dans ce dossier debian/
-<code bash>
-cd debian && ls
-</code>
-Et la, horreur, plein de fichiers à éditer ! Certains éléments de ce squelette ne nous sont pas utiles ici. On va les supprimer :
-<code bash>
-rm -rf *ex *EX README* dirs && ls
-</code>
-Cela supprime le fichier README et les fichiers *.ex et *.EX qui sont des fichiers exemples.
-Il ne nous reste plus que 6 fichiers
-  * changelog
-  * compat
-  * control
-  * copyright
-  * docs
-  * rules
-Le fichier docs n'est pas absolument indispensable mais les cinq autres sont absolument essentiels et il va falloir les éditer avec votre éditeur de texte préféré.
-=== Le fichier ChangeLog ===
-Il contient le détail de toute l'évolution du paquet. Pour chaque entrée on a :
-  * nom_du_paquet_source (version_du_paquet) <distro>; urgency=low
-  * ligne vide
-  * descriptif des changements
-  * ligne vide
-  * nom du packageur <email>  jour, date heure timezone
-Attention à la syntaxe, les espaces et ponctuations ne sont pas anodins. La compilation du paquet source étant très automatisée, les scripts doivent avoir des points de repère solides.
-Quelques mots sur les versions de paquets. Une même version d'un logiciel peut être empaquetée plusieurs fois. De même, Ubuntu étant basée sur Debian, il peut exister plusieurs modifications faites dans Ubuntu à partir du même paquet venant de chez Debian. Les versions sont donc de la forme *<upstream_version>-<debian_version>ubuntu<ubuntu_version>*.
-Ce qui donne pour nous (ePDFView n'existe pas chez debian, donc debian_version = 0) : //0.1.5-0ubuntu1//.
-NB : debian est "upstream" pour ubuntu ("flux venant d'en haut"), de même que les sources du logiciel sont "upstream" pour debian et ubuntu
-il faut donc mettre à jour ce fichier
-  * Avec le nom du paquet
-  * La version
-  * le nom de la distribution (dapper) ou (edgy) à la place de "Unstable" selon la version d'Ubuntu que vous utilisez
-Le "Closes: #nnnn" n'est pas utilisé chez Ubuntu (ça permet de clore automatiquement un bug ITP chez Debian). On peut ici le supprimer.
-Les dates et heures sont à renseigner au format UTC + décalage horaire
-Pour vérifier voici un exemple de [[http://gauvain.tuxfamily.org/school/2006-08-31/debian/changelog| fichier changelog]]
-===Le fichier copyright ===
-Le squelette de ce fichier est plutôt clair, pas vraiment besoin de s'étendre dessus. Mais le contenu n'est pas toujours évident à déterminer. Il y a un fichier COPYING dans le répertoire source, qui contient dans notre exemple la GPL en entier.
-Notez que ce n'est pas ce fichier qui sert de référence pour définir la licence, mais les fichiers source (qui contiennent le code, souvent présents dans un dossier src/).
-Regardez par exemple DocumentRectangle.cxx dans les sources :
-<code bash>less ../src/DocumentRectangle.cxx</code>
-Les quatres premiers paragraphes sont ceux à recopier bêtement (et oui) dans debian/copyright. Ce sont ces paragraphes qui désignent le nom et l'année du Copyright, ainsi que la license (pas le fichier COPYING).
-Attention, vérifiez bien tous les fichiers sources ! Plusieurs copyrights et/ou licences peuvent être utilisés !
-Dans notre cas, le fichier debian/copyright ressemblera à :
-[[http://gauvain.tuxfamily.org/school/2006-08-31/debian/copyright]]
-Il est important de faire attention à ce fichier car s'il est mal renseigné le détenteur du copyright peut très bien aller jusqu'à vous intenter un procès (la majorité se contenteront d'un mail vous signalant l'erreur et si vous êtes courtois n'hésiterons pas à vous aider). Mais soyez prudent malgré tout, certains deviennent susceptibles dès que l'on écorne leur copyright.
-D'ailleurs lors de la réalisation d'un package n'hésitez à contacter l'auteur. C'est en général assez apprécié et cela peut vous permettre de faire valider ce fichier directement auprès de la personne concernée.
-===Le fichier control ===
-C'est le fichier de description du paquet source et de son paquet binaire résultant. Le premier paragraphe décrit le paquet source, le(s) suivant(s) le(s) paquet(s) binaire(s). Les champs présents dans ce fichier squelette **doivent** être présents.
-Jetons un coup d'oeil aux champs concernant le paquet source :
-  * Source: le nom du logiciel que vous packagez
-  * Section: la catégorie dans laquelle pourra se trouver le paquet source (voir [[http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections]] pour la liste des sections)
-  * Priority: l'importance du paquet. Le kernel a en général une importance plus grande qu'un applet pour le panel KDE ;)
-  * Maintainer: Le mainteneur du paquet, en l'occurrence : vous <adresse@foo.bar>
-  * Build-Depends: la liste des paquets nécessaires à la compilation des sources (/!\, les paquets nécessaires à la compilation sont en général différents de ceux nécessaires à l'exécution du programme compilé)
-  * Standards-Version: la version de la "debian policy" actuelle, à laquelle vous devez vous référer ([[http://www.debian.org/doc/debian-policy/]])
-la debian policy peut faire peur... mais c'est la référence pour l'empaquetage debian/ubuntu.
-Pour les champs concernant le paquet binaire nous avons :
-  * Package: le nom du paquet binaire (qui peut différer du nom du paquet source)
-  * Architecture: l'architecture pour laquelle sera valable le paquet binaire. Ça peut être une architecture unique (i386, powerpc...), une liste ou "all" (un seul et même paquet binaire sera utilisable sur toutes les architectures, comme dans le cas d'une application python ou d'un script bash), ou encore "any" (dans ce cas le paquet source doit être compilé sur chacune des architectures disponibles)
-  * Depends: les dépendances du paquet (${shlibs:Depends} sera remplacé plus tard lors de la construction du paquet grâce à un outil fort pratique)
-  * Description: une description courte (d'une ligne), suivie d'une description plus longue (dont chaque ligne commence par un espace).
-C'est cette description qui apparaît dans les propriétés du paquet dans synaptic. Le plus simple est d'aller chercher un texte dans un  fichier readme des sources (s'il y en a un), ou sur le site de l'auteur.
-Il est à noter que l'on peut indiquer ici les paquets supplémentaires suggérés par l'application à l'aide d'une ligne "Suggests: foo1, foo2, foo3" ou "Recommends: bar1, bar2, bar3".
-Voici le fichier control de notre exemple : [[http://gauvain.tuxfamily.org/school/2006-08-31/debian/control]]
-La difficulté principale de cette étape est d'indiquer correctement les Build-Depends. Elles peuvent être déterminées en fouillant les sources ou en compilant à la main l'application (grâce aux messages d'erreurs du ./configure notamment). Elles sont quelquefois indiquées sur le site du projet.
-Attention lors des tests sur votre machine. Il se peut qu'une dépendance nécessaire soit déjà installée et que la compilation fonctionne (à priori) parfaitement. Cependant tous les paquets ubuntu sont compilés dans un environnement vierge. Si la ligne "Build-Depends:" n'est pas exacte, la compilation risque alors d'échouer (pbuilder  est un outil indispensable pour tester les Build Depends, nous en reparlerons plus tard).
-==le paquet debhelper==
-Dans la ligne Build-Depends figure la mention d'un paquet particulier : le paquet debhelper.
-debhelper est un outil qui facilite la vie des empaqueteurs, avec tout un tas de petits scripts dont les noms commencent par 'dh_'. Chacun a un rôle particulier et fonctionne différemment. `man dh_truc` vous apprendra tout ce qu'il faut savoir ;) On verra quelques exemples en regardant le fichier debian/rules. La version de référence pour Ubuntu Dapper et Edgy et la version 5. la "compatibilité debhelper" (cf paragraphe suivant) correspond à la version majeure de debhelper (5 donc). dh_make utilise par défaut une compatibilité debhelper 4 sous dapper. Veillez à mettre à jour les informations (bien que ce ne soit à priori pas vital pour la compilation de votre paquet).
-===Le fichier compat ===
-Ce fichier sert à indiquer la compatibilité debhelper.
-===Le fichier rules ===
-Le fichier rules est un fichier exécutable. C'est lui qui va servir à piloter la compilation lors de la création du paquet binaire.
-C'est ce fichier qui contient les règles nécessaire à la compilation du paquet. Le principe est simple. Il s'agit tout simplement de compiler le logiciel exactement comme on compile avec `./configure && make`(c'est la règle "build"), et de l'installer (c'est la règle "install") non pas sur le système, mais dans un dossier ("$(CURDIR)/debian/<paquet>", avec `make install`), avant de pouvoir en faire une archive .deb (c'est la règle "binary-install").
-Le fichier rules est un makefile  dont chaque cible est appelée lors de la construction du paquet. Chaque partie correspond en fait à une certaine étape de la compilation :
-  * config.status: correspond au `./configure` (avec un paquet d'options dans notre fichier rules)
-  * build: correspond au `make` ($(MAKE))
-  * install: correspond au `make install`
-Ici l'installation se fait dans "$(CURDIR)/debian/epdfview", donc dans le dossier debian/ créé tout à l'heure.
-Le fichier rules que vous avez n'a pas à être modifié pour notre exemple.
-En général il n'est pas nécessaire de le modifier, c'est uniquement dans le cas ou la compilation classique (./configure && make && make install) échoue que cela devient nécessaire (dans le cas d'un logiciel utilisant cette méthode de compilation, bien sûr).
-Par contre si l'on veut ajouter des éléments particuliers à l'installation (script shell supplémentaire ou page man par exemple), c'est dans ce fichier qu'on le précise.
-On va d'ailleurs ajouter une page man à notre exemple :
-<code bash >
-wget http://gauvain.tuxfamily.org/school/2006-08-31/debian/epdfview.1
-</code>
-Cette page est à installer dans ~/packaging/epdvfiew/epdfview-0.1.5/debian
-Si vous ajoutez un fichier dans les sources c'est **toujours et uniquement** dans le dossier **debian**. Les sources de l'auteur ne doivent en aucun cas être directement modifiées (vous pouvez utiliser un système de patch tel que dpatch ou simple-patchsys, ce que nous n'aborderons pas ici).
-Pour indiquer que l'on veut ajouter cette page man on va utiliser l'outil dh_installman. Cela va se faire via le fichier debian/rules.
-Cherchez dans votre fichier rules la ligne qui contient //dh_installman// (normalement ligne 92 ou 93). On va préciser quelle page man on veut installer en la changeant en
-<code>
-dh_installman debian/epdfview.1
-</code>
-(vous aurez remarqué que dh_installman fait partie des outils du paquet debhelper.)
-Pour avoir des informations sur tous les outils dh_* que vous voyez listé dans ce fichier n'hésitez pas à consulter les pages man. Une bonne partie d'entre elles seront francisées (n'oubliez pas d'installer le paquet manpages-fr pour pouvoir les lires).
-Une fois arrivé ici notre paquet source est prêt, il ne nous reste plus qu'a le créer vraiment pour pouvoir retrouver les trois fichiers que nous avons vu plus tôt, dans notre premier exemple.
-Pour construire ce paquet :
-<code bash>
-cd .. # on se place à la racine du dossier source : ~/packaging/epdfview/epdfview-0.1.5
-debuild -S -sa
-</code>
-Le '-S' permet de construire un paquet source, le '-sa' permet d'inclure le .orig.tar.gz dans l'upload vers une archive (à retenir lorsque vous uploaderez votre premier paquet sur [[http://revu.tauware.de| REVU]], le système de QA d'Ubuntu, permettant aux contributeurs de faire rentrer des paquets et surtout, comme son nom l'indique, de les faire vérifier par des MOTUs).
-À ce stade vous risquez d'être confronté à l'erreur suivante :
-<code>
-debuild: fatal error at line 791:
-running debsign failed
-</code>
-Pas de panique contrairement, à ce qui est indiqué ce n'est pas une erreur si fatale que cela. Elle signifie simplement que debuild n'a pas pu signé le paquet avec une clef gpg\\
-Si vous avez une clef gpg associée à l'adresse mail que vous avez indiqué au début, vous pouvez utiliser **-kIDdelaclé** comme paramètre supplémentaire de debuild. Une autre solution est d'ajouter dans votre fichier **.bashrc** (dans votre $HOME) export GPGKEY=<id_de_la_clé> pour qu'elle soit prise en compte automatiquement.
-Pour voir le résultat
-<code bash> cd .. && ls </code>
-et, Oh miracle ! nous avons bien nos trois fichiers !
-====Compilation et création du paquet binaire====
-===Préparation de pbuilder===
-On va utiliser l'outil pbuilder, qui crée un chroot d'un système ubuntu de base, puis le compresse dans un fichier base.tgz.\\
-Lors de l'utilisation de pbuilder pour construire le paquet binaire, le chroot va être décompressé, les Build-Deps installées, et le paquet compilé. S'il manque une Build-Dep, la compilation échouera.\\
-Le principal intérêt de pbuilder est de vérifier que les Build Deps sont bonnes (cf. notre fichier control).
-Pour initialiser pbuider, tapez dans votre terminal :
-<code bash>
-cp /etc/pbuilderrc ~/.pbuilderrc && sed -i 's/^\#COMPONENTS/COMPONENTS/' ~/.pbuilderrc
-sudo pbuilder create --distribution dapper
-</code>
-La première ligne permet d'activer l'utilisation des dépôts universe et multiverse sous dapper (désactivés par défaut). La seconde crée le chroot et le compresse.
-Ces commandes peuvent être lancées en début de travail dans un autre terminal, car cette étape peut prendre un certain temps. N'étant utilisé qu'a la fin vous pouvez très bien commencer à préparer vos paquets sources pendant ce temps.
-===Création du paquet binaire===
-Une fois l'étape précédente terminée il ne vous reste plus qu'a taper la commande suivante pour compiler votre paquet source (dans ~/packaging/epdfview) :
-<code bash>
-sudo pbuilder build *dsc
-</code>
-Et à laisser mariner...
-Une fois cette étape terminée, votre .deb est dans **/var/cache/pbuilder/result**
-En dernière étape, nous allons vérifier quelques points :
-  * d'abord les dépendances
-<code bash>
-dpkg -f /var/cache/pbuilder/result/epdfview*deb
-</code>
-Notez que la variable ${shlibs:Depends} a été remplacée par une liste de bibliothèques (avec précision des versions pour certaines).
-  * la liste des fichiers contenus dans le .deb
-<code bash>
-dpkg -c /var/cache/pbuilder/result/epdfview*deb
-</code>
-  * Utilisons enfin lintian, qui permet de vérifier la qualité des .debs et des paquets source (par rapport à la debian policy) :
-<code bash>
-lintian -Iv /var/cache/pbuilder/result/epdfview*deb # pour le binaire
-lintian -Iv ~/packaging/epdfview/*dsc # pour le paquet source
-</code>
-Cet avertissement de lintian :
->> W: epdfview: old-fsf-address-in-copyright-file
-n'est pas un bloqueur.
-Linda fonctionne de la même manière que lintian.
-====== Conclusion ======
-Vous avez donc maintenant votre paquet debian compilé et prêt à être diffusé (à vous de trouver le moyen de le faire, le plus simple étant de vous joindre à une équipe gérant déjà un dépôt existant. Cela vous permettra d'être en contact avec des gens ayant déjà de l'expérience qui pourront vous en faire profiter).