Guide du nouveau responsable Debian
---------------------------------------------------------------------
Josip Rodin
version initiale <joy-mg@debian.org>
Osamu Aoki
version mise à jour <osamu@debian.org>
Frédéric Dumont
traduction française <frederic.dumont@easynet.be>
Mohammed Adnène Trojette
traduction française <adn+deb@diwi.org>
David Prévot
traduction française <david@tilapin.org>
les membres de la liste debian-l10n-french
traduction française <debian-l10n-french@lists.debian.org>
version 1.2.53
---------------------------------------------------------------------
Copyright © 1998-2002 Josip Rodin
Copyright © 2005-2015 Osamu Aoki
Copyright © 2010 Craig Small
Copyright © 2010 Raphaël Hertzog
Ce document peut être utilisé selon les termes de la Licence
publique générale de GNU version 2 ou suivante.
Ce document a été créé en se basant sur les deux suivants :
* Making a Debian Package (le manuel de debmake), copyright ©
1997 Jaldhar Vyas.
* The New-Maintainer's Debian Packaging Howto, copyright © 1997
Will Lowe.
The rewrite of this tutorial document with updated contents
and more practical examples is available as "Guide for Debian
Maintainers". Please use this new tutorial as the primary
tutorial document.
2022-10-08 03:52:48 UTC
---------------------------------------------------------------------
Table des matières
1. Partir du bon pied
1.1. Dynamique sociale de Debian
1.2. Programmes nécessaires au développement
1.3. Documentation nécessaire au développement
1.4. Où demander de l'aide
2. Premiers pas
2.1. Processus de construction de paquet Debian
2.2. Choix du programme
2.3. Obtenir le programme et l'essayer
2.4. Systèmes de construction simples
2.5. Systèmes de construction portables répandus
2.6. Nom et version de paquet
2.7. Configuration de dh_make
2.8. Paquet Debian non natif initial
3. Modification du code source
3.1. Configuration de quilt
3.2. Correction de bogues amont
3.3. Installation des fichiers à leur emplacement
3.4. Bibliothèques différentes
4. Fichiers nécessaires dans le répertoire debian
4.1. control
4.2. copyright
4.3. changelog
4.4. rules
4.4.1. Cibles du fichier rules
4.4.2. Fichier rules par défaut
4.4.3. Personnalisation du fichier rules
5. Autres fichiers dans le répertoire debian
5.1. README.Debian
5.2. compat
5.3. conffiles
5.4. paquet.cron.*
5.5. dirs
5.6. paquet.doc-base
5.7. docs
5.8. emacsen-*
5.9. paquet.examples
5.10. paquet.init et paquet.default
5.11. install
5.12. paquet.info
5.13. paquet.links
5.14. {paquet.,source/}lintian-overrides
5.15. manpage.*
5.15.1. manpage.1.ex
5.15.2. manpage.sgml.ex
5.15.3. manpage.xml.ex
5.16. paquet.manpages
5.17. NEWS
5.18. {post,pre}{inst,rm}
5.19. paquet.symbols
5.20. TODO
5.21. watch
5.22. source/format
5.23. source/local-options
5.24. source/options
5.25. patches/*
6. Construction du paquet
6.1. Reconstruction complète
6.2. Serveurs d'empaquetage automatique (« autobuilder »)
6.3. Commande debuild
6.4. Paquet pbuilder
6.5. Commandes git-buildpackage et similaires
6.6. Reconstruction rapide
6.7. Hiérarchie des commandes
7. Contrôle des erreurs du paquet
7.1. Modifications suspectes
7.2. Vérification de l'installation d'un paquet
7.3. Vérification des scripts du responsable d'un paquet
7.4. Utilisation de lintian
7.5. Commande debc
7.6. Commande debdiff
7.7. Commande interdiff
7.8. Commande mc
8. Mise à jour de paquet
8.1. Nouvelle révision Debian
8.2. Examen d'une nouvelle version amont
8.3. Nouvelle version amont
8.4. Mise à jour du style d'empaquetage
8.5. Conversion en UTF-8
8.6. Rappels pour la mise à jour de paquets
9. Envoi de paquet
9.1. Envoi vers l'archive Debian
9.2. Inclusion de orig.tar.gz pour l'envoi
9.3. Versions non envoyées
A. Empaquetage avancé
A.1. Bibliothèques partagées
A.2. Gestion de debian/paquet.symbols
A.3. Multiarchitecture
A.4. Construction d'un paquet de bibliothèque partagée
A.5. Paquet Debian natif
Chapitre 1. Partir du bon pied
La réécriture de ce tutoriel avec des contenus à jour et des
exemples pratiques supplémentaires est disponible sur Guide du
responsable Debian. Veuillez utiliser ce nouveau tutoriel comme
document principal.
Ce document essaie de décrire aux utilisateurs Debian moyens, et
aux développeurs en devenir, la construction d'un paquet Debian.
Il utilise un langage pas trop technique et est complété par des
exemples, selon le vieux proverbe latin : « Longum iter est per
praecepta, breve et efficax per exempla » (c'est long par la
règle, court et efficace par l'exemple).
This document is made available for the Debian Buster release
since this offers many translations. This document will be
dropped in the following releases since contents are getting
outdated. ^[1]
Une des choses qui font de Debian une distribution de si haut
niveau est son système de paquets. Bien qu'il existe une grande
quantité de logiciels au format Debian, vous devrez parfois
installer un logiciel qui ne l'est pas. Vous pouvez vous demander
comment faire vos propres paquets et peut-être pensez-vous que
c'est une tâche très difficile. Eh bien, si vous êtes vraiment un
débutant sous Linux, c'est dur, mais si vous étiez un débutant,
vous ne seriez pas en train de lire ce document. :-) Vous devez
en savoir un peu sur la programmation UNIX, mais vous n'avez
certainement pas besoin d'être un magicien. ^[2]
Une chose est sûre, cependant : créer et maintenir correctement
des paquets Debian prend beaucoup de temps. Ne vous faites pas
d'illusion, pour que votre système fonctionne, les responsables
doivent à la fois être techniquement compétents et consciencieux.
Si vous avez besoin d'aide sur l'empaquetage, veuillez consulter
Section 1.4, « Où demander de l'aide ».
Les nouvelles versions de ce document devraient toujours être
disponibles en ligne sur http://www.debian.org/doc/maint-guide/.
La version de référence en anglais est disponible sur http://
www.debian.org/doc/maint-guide/index.en.html et dans le paquet
maint-guide. La traduction en français est également disponible
dans le paquet maint-guide-fr.
Puisqu'il s'agit d'un tutoriel, il a été choisi d'expliquer de
façon détaillée chaque étape pour certains sujets importants.
Certains d'entre eux pourraient vous sembler hors sujet. Veuillez
être patient. Certains cas particuliers ont été sautés, et seuls
des liens ont été fournis pour conserver la simplicité de ce
document.
1.1. Dynamique sociale de Debian
Voici quelques observations sur la dynamique sociale de Debian,
en espérant qu'elles puissent vous préparer à interagir avec
Debian :
* Nous sommes tous bénévoles.
+ Vous ne pouvez pas forcer les autres à faire quoi que ce
soit.
+ Vous devriez être motivé à faire des choses vous-même.
* La coopération amicale est la force motrice.
+ Vos contributions ne devraient pas surmener les autres.
+ Vos contributions n'ont de sens que si les autres les
apprécient.
* Debian n'est pas une école où vous attirez automatiquement
l'attention des professeurs.
+ Vous devriez être capable d'apprendre la plupart des
choses par vous-même.
+ L'attention des autres bénévoles est une ressource très
rare.
* Debian s'améliore sans cesse.
+ On s'attend à ce que vous fassiez des paquets de haute
qualité.
+ Vous devrez vous adapter vous-même aux modifications.
Plusieurs sortes de personnes ont rapport à Debian avec différent
rôles :
* auteur amont : la personne qui a créé le programme à
l'origine ;
* responsable amont : la personne qui maintient actuellement le
programme ;
* responsable : la personne qui maintient le paquet Debian du
programme ;
* parrain : une personne qui aide les responsables à envoyer
des paquets dans l'archive officielle de paquets Debian
(après en avoir vérifié le contenu) ;
* mentor : une personne qui aide les responsables débutants
pour l'empaquetage, etc. ;
* développeur Debian (DD) : un membre du projet Debian avec
tous les droits d'envoi vers l'archive officielle de paquets
Debian ;
* responsable Debian (DM) : une personne avec des droits
d'envoi limités vers l'archive officielle de paquets Debian.
Veuillez remarquer qu'il n'est pas possible de devenir
développeur Debian (DD) en une nuit car il ne suffit pas de
compétences techniques. Veuillez ne pas vous décourager. Si c'est
utile à d'autres, vous pouvez toujours envoyer vos paquets, soit
en tant que responsable à l’aide d’un parrain, soit comme un
responsable Debian.
Remarquez qu'il n'est pas nécessaire de créer de nouveau paquet
pour devenir un développeur Debian officiel. Contribuer aux
paquets existants peut aussi fournir une voie pour devenir un
développeur Debian. Beaucoup de paquets sont en attente de bons
responsables (consultez Section 2.2, « Choix du programme »).
Puisque nous nous concentrons dans ce document exclusivement sur
les aspects techniques de l'empaquetage, veuillez consulter les
documents suivants pour apprendre comment Debian fonctionne et
comment vous investir :
* Debian : 17 ans de logiciel libre, « do-ocracy » et
démocratie (diapositives introductives en anglais)
* Comment pouvez-vous aider Debian ? (officiel)
* La FAQ Debian GNU/Linux, Chapitre 13 — Participer au projet
Debian (semi-officiel)
* Wiki Debian, HelpDebian (supplémentaire)
* Site du nouveau membre Debian (officiel)
* FAQ de Debian Mentors (supplémentaire)
1.2. Programmes nécessaires au développement
Avant de commencer quoi que ce soit, vous devriez vous assurer
d'avoir correctement installé certains paquets nécessaires au
développement. Notez que la liste ne contient aucun paquet marqué
essential ou required (essentiel ou requis) — nous supposons que
ceux-ci sont déjà installés.
Les paquets suivants sont fournis dans l'installation standard de
Debian, de sorte que vous les avez probablement déjà (ainsi que
les paquets supplémentaires dont ils dépendent). Néanmoins, vous
devriez le vérifier avec aptitude show paquet ou avec dpkg -s
paquet.
Le paquet le plus important à installer sur un système de
développement est build-essential. Lors de son installation, il
tirera avec lui d'autres paquets nécessaires à un environnement
de compilation de base.
Pour certaines catégories de paquets, c'est tout ce dont vous
aurez besoin. Cependant d'autres paquets, bien que non essentiels
à toutes les constructions de paquet, sont utiles ou peuvent être
nécessaires pour votre paquet :
* autoconf, automake et autotools-dev — beaucoup de nouveaux
programmes utilisent des scripts de configuration et des
fichiers Makefile prétraités à l'aide de programmes comme
ceux-ci (consultez info autoconf et info automake).
autotools-dev conserve les versions à jour de certains de ces
fichiers automatiques et fournit une documentation sur la
meilleure façon d'utiliser ces fichiers ;
* debhelper et dh-make — dh-make est nécessaire pour créer le
squelette de notre exemple de paquet et il utilise certains
outils de debhelper pour créer les paquets. Ils ne sont pas
indispensables pour cela, mais sont fortement recommandés
pour les nouveaux responsables. Ils rendent le processus
complet bien plus facile à démarrer et à contrôler par la
suite (consultez dh_make(8) et debhelper(1)) ^[3] ;
Le nouveau paquet debmake peut être utilisé comme alternative
au paquet standard dh-make. Il est plus puissant et fourni
avec une documentation HTML incluant des exemples complets
d’empaquetage dans debmake-doc.
* devscripts — ce paquet contient des scripts utiles pouvant
aider les responsables, mais ils ne sont pas indispensables
pour la création de paquets. Les paquets recommandés et
suggérés par celui-ci valent le coup d'œil (consultez /usr/
share/doc/devscripts/README.gz) ;
* fakeroot — cet utilitaire vous laisse prétendre être le
superutilisateur, ce qui est nécessaire pour certaines
parties du processus de construction (consultez fakeroot(1))
;
* file — ce programme pratique peut déterminer la nature d'un
fichier (consultez file(1)) ;
* gfortran — le compilateur Fortran 95 de GNU, nécessaire si
votre programme est écrit en Fortran (consultez gfortran(1))
;
* git — ce paquet fournit un système populaire de gestion de
versions conçu pour manipuler de très gros projets rapidement
et efficacement ; il est utilisé pour des projets libres de
grande envergure, en particulier le noyau Linux (consultez
git(1) et le manuel de Git, /usr/share/doc/git-doc/
index.html).
* gnupg — un outil qui vous permet de signer numériquement les
paquets. Cela est spécialement important si vous comptez les
distribuer à d'autres personnes, et c'est certainement ce que
vous ferez quand votre travail sera inclus dans la
distribution Debian (consultez gpg(1)) ;
* gpc — le compilateur Pascal de GNU, nécessaire si votre
programme est écrit en Pascal. Méritant d'être mentionné ici,
fp-compiler, le compilateur Pascal libre, convient également
(consultez gpc(1), ppc386(1)) ;
* lintian — c'est le vérificateur de paquet Debian, qui peut
indiquer de nombreuses erreurs courantes après la
construction du paquet et expliquer les erreurs trouvées
(consultez lintian(1) et le manuel utilisateur de Lintian) ;
* patch — ce programme très utile prend un fichier contenant
une liste de différences (produite par le programme diff) et
l'applique au fichier original, produisant une version
modifiée (consultez patch(1)) ;
* patchutils — ce paquet contient certains utilitaires pour
travailler avec les correctifs comme les commandes lsdiff,
interdiff et filterdiff ;
* pbuilder — ce paquet contient des programmes utilisés pour
créer et maintenir un environnement « chrooté ». Construire
un paquet Debian dans cet environnement permet de vérifier
les dépendances correctes de construction et évite les bogues
FTBFS (« Fails To Build From Source » pour les échecs de
construction à partir du paquet source) (consultez pbuilder
(8) et pdebuild(1)) ;
* perl — Perl est un des langages de script les plus utilisés
sur les systèmes modernes similaires à UNIX, souvent qualifié
de « tronçonneuse suisse d'UNIX » (consultez perl(1)) ;
* python — Python fait aussi partie des langages de script les
plus utilisés sur le système Debian, combinant une
remarquable puissance et une syntaxe très claire (consultez
python(1)) ;
* quilt — ce paquet aide à gérer un grand nombre de correctifs
en gardant une trace du rôle de chacun. Les correctifs
peuvent être appliqués, enlevés, rafraîchis, etc. (consultez
quilt(1) et /usr/share/doc/quilt/quilt.pdf.gz) ;
* xutils-dev — certains programmes, d'ordinaire ceux conçus
pour X11, utilisent aussi ces programmes pour générer les
fichiers Makefile à partir d'un ensemble de fonctions macros
(consultez imake(1), xmkmf(1)) ;
Les courtes descriptions données ci-dessus ne servent qu’à vous
présenter ce que fait chaque paquet. Avant de continuer, veuillez
lire la documentation de chaque programme pertinent, y compris
ceux installés par les dépendances du paquet comme make, au moins
celle concernant l'utilisation standard. Cela peut vous sembler
fastidieux maintenant, mais plus tard vous serez très content de
l'avoir fait. Si vous avez des questions particulières par la
suite, vous devriez relire les documents mentionnés ci-dessus.
1.3. Documentation nécessaire au développement
Les documents suivants sont très importants et doivent être lus
en parallèle à ce document :
* debian-policy — la Charte Debian inclut des explications sur
la structure et le contenu de l'archive Debian, plusieurs
considérations sur l'architecture du système d'exploitation,
la norme de hiérarchie des fichiers (« Filesystem Hierarchy
Standard » ou FHS, qui définit où chaque fichier et
répertoire doivent se trouver), etc. Le plus important pour
vous est qu'elle décrive les critères que chaque paquet doit
vérifier pour être inclus dans la distribution (consultez les
copies locales de /usr/share/doc/debian-policy/policy.pdf.gz
et /usr/share/doc/debian-policy/fhs/fhs-3.0.pdf.gz) ;
* developers-reference — la Référence du développeur Debian
concerne tout ce qui n'est pas spécifique aux détails
techniques de la création de paquets, comme la structure des
archives, comment renommer, abandonner, adopter les paquets,
faire une NMU (« Non-Maintainer Uploads » ou mise à jour
indépendante), comment gérer les bogues, les meilleures
pratiques d'empaquetage, où et quand faire des envois de
paquets, etc. (consultez la copie locale de /usr/share/doc/
developers-reference-fr/developers-reference.pdf) ;
Les documents suivants sont importants et doivent être lus en
parallèle à ce document :
* Le tutoriel des Autotools fournit un très bon tutoriel pour
le système de construction GNU connu sous le nom de GNU
Autotools dont les composants les plus importants sont
Autoconf, Automake, Libtool et gettext ;
* gnu-standards — ce paquet contient deux documentations issues
du projet GNU : les normes GNU de codage, et les informations
pour les responsables de programme GNU. Bien que Debian
n'exige pas que ces recommandations soient suivies, elles
sont néanmoins utiles en tant que lignes directrices et bon
sens (consultez les copies locales de /usr/share/doc/
gnu-standards/standards.pdf.gz et /usr/share/doc/
gnu-standards/maintain.pdf.gz).
Si ce document contredit n'importe quelle documentation
précédente, celle-ci est prioritaire. Veuillez signaler un bogue
sur le paquet maint-guide avec reportbug.
Voici un autre tutoriel qui peut être lu en parallèle de ce
document :
* tutoriel d'empaquetage Debian ;
1.4. Où demander de l'aide
Avant de vous décider à poser publiquement une question, veuillez
lire ces excellentes documentations :
* fichiers de /usr/share/doc/paquet pour tous les paquets
appropriés ;
* contenu de man commande pour tous les paquets appropriés ;
* contenu de info commande pour tous les paquets appropriés ;
* contenu des archives de la liste de diffusion
debian-mentors@lists.debian.org ;
* contenu des archives de la liste de diffusion
debian-devel@lists.debian.org.
Vous pouvez utiliser les moteurs de recherche web plus
efficacement en indiquant des chaînes de recherche comme
site:lists.debian.org pour limiter le domaine.
Faire un petit paquet de test est une bonne façon d'apprendre les
particularités de l'empaquetage. Examiner les paquets bien
maintenus est le meilleur moyen d'apprendre comment les autres
font leurs paquets.
Si vous avez encore des questions sur la création de paquets pour
lesquelles vous n'avez pas pu trouver de réponse dans la
documentation disponible ou sur la toile, vous pouvez les poser
de façon interactive :
* liste de diffusion debian-mentors@lists.debian.org (cette
liste est pour les débutants) ;
* liste de diffusion debian-devel@lists.debian.org (cette liste
est pour les spécialistes) ;
* IRC, par exemple #debian-mentors ;
* équipes se concentrant sur un ensemble particulier de paquets
(liste complète à https://wiki.debian.org/Teams) ;
* listes de diffusion de certaines langues comme debian-devel-
{french,italian,portuguese,spanish}@lists.debian.org ou
debian-devel@debian.or.jp (liste complète à https://
lists.debian.org/devel.html et https://lists.debian.org/
users.html).
Les responsables Debian les plus expérimentés seront heureux de
vous aider, si vous demandez correctement après avoir fait les
efforts nécessaires.
Quand vous recevrez un rapport de bogue (oui, un vrai rapport de
bogue !), vous saurez qu'il est temps de vous plonger dans le
système de suivi de bogues Debian et de lire la documentation,
pour être à même de gérer les rapports efficacement. La lecture
de la référence du développeur Debian, chapitre
5.8. « Manipulation des bogues » est fortement recommandée.
Même si tout fonctionne bien, il est temps de commencer à prier.
Pourquoi ? Parce que dans quelques heures (ou jours) les
utilisateurs du monde entier vont commencer à utiliser votre
paquet, et si vous avez fait des erreurs critiques, vous serez
bombardé par les courriers électroniques d'utilisateurs Debian
furieux… :-)
Relaxez-vous et soyez prêt pour les rapports de bogues, parce
qu'il y aura beaucoup plus de travail à faire avant que votre
paquet ne soit parfaitement conforme aux règles Debian (une fois
encore, lisez la vraie documentation pour les détails). Bonne
chance !
---------------------------------------------------------------------
^[1] Ce document suppose que vous utilisez un système Jessie ou
plus récent. Si vous avez l'intention de suivre ce texte avec un
système plus ancien (y compris un ancien système Ubuntu par
exemple), vous devez au moins installer les paquets dpkg et
debhelper rétroportés.
^[2] Vous pouvez apprendre les bases du système Debian à partir
de la Référence Debian. Elle contient aussi quelques liens pour
apprendre la programmation UNIX.
^[3] D'autres paquets plus spécialisés mais similaires existent
aussi comme dh-make-perl, dh-make-php, etc.
Chapitre 2. Premiers pas
La réécriture de ce tutoriel avec des contenus à jour et des
exemples pratiques supplémentaires est disponible sur Guide du
responsable Debian. Veuillez utiliser ce nouveau tutoriel comme
document principal.
Commencez par créer votre propre paquet (ou, encore mieux, par en
adopter un).
2.1. Processus de construction de paquet Debian
Si vous faites un paquet Debian à partir d'un programme amont, le
processus typique de construction de paquet Debian implique de
créer plusieurs fichiers au nom spécifique pour chaque étape
comme suit :
* obtenir une copie du logiciel amont, généralement distribuée
sous la forme d'un fichier au format tar compressé :
+ paquet-version.tar.gz
* ajouter les modifications spécifiques à Debian au programme
amont dans le répertoire debian, et créer un paquet source
non natif (c'est-à-dire, le jeu de fichiers d'entrée utilisés
pour la construction du paquet Debian) au format 3.0 (quilt)
:
+ paquet_version.orig.tar.gz
+ paquet_version-révision.debian.tar.gz^[4]
+ paquet_version-révision.dsc
* construire les paquets binaires Debian, qui sont des fichiers
de paquet installable classique au format .deb (ou .udeb pour
l'installateur Debian) à partir du paquet source Debian :
+ paquet_version-révision_arch.deb
Veuillez remarquer que le caractère séparant paquet de version a
été modifié : le tiret (-) dans le nom de l'archive source a été
remplacé par un tiret bas (_) dans les noms de fichier de paquet
Debian.
Dans les noms de fichier précédents, la partie paquet du nom de
fichier est remplacée par le nom du paquet, la partie version par
la version amont, la partie révision par la révision Debian et la
partie arch par l'architecture du paquet, conformément à la
Charte Debian. ^[5]
Chaque étape de ces grandes lignes sera expliquée avec des
exemples détaillés dans les sections suivantes.
2.2. Choix du programme
Vous avez probablement choisi le paquet que vous voulez créer. La
première chose à faire est de vérifier si le paquet ne se trouve
pas déjà dans l'archive de la distribution en utilisant ce qui
suit :
* la commande aptitude ;
* la page des paquets Debian ;
* la page web du système de suivi de paquets Debian.
Si le paquet existe déjà, et bien, installez-le :-). S'il se
trouve qu'il est orphelin (c'est à dire si son responsable est
Debian QA Group), vous devriez pouvoir le reprendre s'il est
toujours disponible. Vous pouvez aussi adopter un paquet dont le
responsable a rempli une demande d'adoption (« Request for
Adoption » ou RFA).^[6]
Plusieurs ressources d'état de propriété de paquet Debian
existent :
* La commande wnpp-alert du paquet devscripts ;
* liste des paquets en souffrance et paquets souhaités ;
* journal de rapports de bogue Debian : bogues du pseudo-paquet
wnpp dans unstable ;
* paquets Debian en manque d'amour ;
* naviguer parmi les bogues wnpp en fonction des debtags.
En remarque, il est important de souligner que Debian possède
déjà des paquets pour quasiment tous les types de programme, et
que le nombre de paquets déjà dans l'archive Debian est bien plus
important que le nombre de personnes ayant les droits suffisants
pour envoyer les mises à jour. Par conséquent, contribuer aux
paquets existants déjà dans l'archive est bien plus apprécié
(avec plus de chances d'être parrainé) des autres développeurs ^
[7]. Il est possible de contribuer de plusieurs façons comme
suit :
* se charger de paquets orphelins, encore largement utilisés ;
* rejoindre des équipes d'empaquetage ;
* trier des bogues de paquets populaires ;
* préparer des envois de QA ou des NMU.
Si vous pouvez adopter le paquet, récupérez les sources (avec
quelque chose comme apt-get source nomdepaquet) et examinez-les.
Malheureusement ce document n'inclut pas d'informations
exhaustives sur l'adoption de paquets. Heureusement, vous ne
devriez pas avoir de problèmes à comprendre comment le paquet
fonctionne, puisque quelqu'un s'est déjà occupé de la
configuration initiale pour vous. Continuez quand même à lire ce
document, une bonne partie des conseils qui suivent seront
applicables dans votre cas.
Si le paquet est nouveau, et que vous aimeriez le voir dans
Debian, procédez comme suit :
* d'abord, assurez-vous que le programme fonctionne, et
essayez-le pendant quelques temps pour confirmer son
utilité ;
* vérifiez que personne d'autre ne travaille déjà sur ce paquet
en consultant la liste des paquets en souffrance et paquets
souhaités. Si personne ne travaille dessus, déclarez votre
intention de l'empaqueter (« Intent To Package » ou ITP) avec
un bogue ITP sur le pseudo-paquet wnpp en utilisant reportbug
. Si quelqu'un travaille déjà dessus, contactez-le si vous
voulez. Sinon, trouvez un autre programme intéressant dont
personne ne s'occupe ;
* le logiciel doit avoir une licence :
+ pour la section main (principale), la Charte Debian exige
qu'il soit totalement conforme aux principes du logiciel
libre selon Debian (« Debian Free Software Guidelines »
ou DFSG) et qu’il ne dépende pas de paquets hors de main
pour la compilation ou l'exécution. C'est le cas idéal ;
+ pour la section contrib (contributions), il doit être
conforme à tous les DFSG mais peut dépendre de paquets
hors de main pour la compilation ou l'exécution ;
+ pour la section non-free (non libre), il peut être non
conforme aux DFSG mais doit être distribuable ;
+ en cas de doute sur la section à laquelle il devrait
appartenir, envoyez la licence sur
debian-legal@lists.debian.org et demandez conseil.
* le programme ne devrait pas introduire dans Debian de
problèmes relatifs à la sécurité et à la maintenance :
+ le programme devrait être bien documenté, et le code doit
être compréhensible (c'est-à-dire, pas volontairement
obscur) ;
+ vous devriez contacter les auteurs du programme pour
vérifier qu'ils sont d'accord pour la création du paquet
et bienveillants envers Debian. Il est important de
pouvoir consulter les auteurs en cas de problèmes
spécifiques au programme, n'essayez donc pas de créer un
paquet à partir d'un logiciel non maintenu ;
+ le programme ne devrait certainement pas être exécuté
setuid root, ou encore mieux, il ne devrait pas être
setuid ou setgid pour quoi que ce soit ;
+ le programme ne devrait ni être un démon, ni s'installer
dans un répertoire */sbin, ni ouvrir un port en tant que
superutilisateur.
Bien sûr, cette dernière remarque n'est qu'une mesure de
sécurité, et n'a pour but que de vous préserver d'utilisateurs
fous de rage si vous faites une erreur dans un démon setuid…
Quand vous aurez plus d'expérience dans la création de paquets,
vous pourrez empaqueter un logiciel de ce type.
En tant que nouveau responsable vous devriez acquérir de
l'expérience dans l'empaquetage de paquets plus faciles plutôt
que de créer des paquets compliqués :
* paquets simples :
+ paquet binaire unique, arch = all (collection de données
comme par exemple des fonds d'écran),
+ paquet binaire unique, arch = all (exécutables écrits en
langage interprété comme le shell POSIX) ;
* paquet de complexité intermédiaire :
+ paquet binaire unique, arch = any (exécutables binaires
ELF provenant de langages comme C ou C++),
+ plusieurs paquets binaires, arch = any + all (paquets
pour exécutables binaires ELF et documentation),
+ sources amont dans un autre format que tar.gz ou tar.bz2,
+ sources amont contenant du contenu non distribuable ;
* paquets plus compliqués :
+ paquet de module interpréteur utilisé par d'autres
programmes,
+ paquet de bibliothèque générique ELF utilisé par d'autres
paquets,
+ plusieurs paquets binaires dont un paquet de bibliothèque
ELF ;
+ paquet source avec plusieurs sources amont,
+ paquets de modules du noyau,
+ paquets de correctifs du noyau,
+ paquets avec des scripts du responsable non triviaux.
Ce n'est pas si difficile d'empaqueter des paquets plus
compliqués, mais cela exige un peu plus de connaissances. Vous
devriez chercher de l'aide particulière pour chaque
fonctionnalité compliquée. Par exemple, certains langages ont
leur propre sous-charte :
* charte Perl ;
* charte Python ;
* charte Java.
Un autre vieux proverbe latin s'applique : « fabricando fit faber
» (c'est en forgeant que l'on devient forgeron). La pratique et
l'expérience de toutes les étapes de l'empaquetage sont vivement
recommandées avec des paquets simples lors de la lecture de ce
tutoriel. Une archive source amont triviale comme
hello-sh-1.0.tar.gz créée comme suit peut servir de bon point de
départ : ^[8]
$ mkdir -p hello-sh/hello-sh-1.0; cd hello-sh/hello-sh-1.0
$ cat > hello <<EOF
#!/bin/sh
# (C) 2011 Truc Bidule, GPL2+
echo "Bonjour !"
EOF
$ chmod 755 hello
$ cd ..
$ tar -cvzf hello-sh-1.0.tar.gz hello-sh-1.0
2.3. Obtenir le programme et l'essayer
La première chose à faire est de trouver et télécharger le code
source d'origine. Supposons que vous ayez déjà le fichier source
pris sur la page web de l'auteur. Les sources pour les logiciels
UNIX libres sont d'habitude distribuées au format tar+gzip avec
l'extension .tar.gz, au format tar+bzip2 avec l'extension
.tar.bz2 ou au format tar+xz avec l’extension .tar.xz. Elles
contiennent normalement un sous-répertoire nommé paquet-version
avec toutes les sources dedans.
Si la dernière version de la source est disponible dans un dépôt
de gestion de versions tel que Git, Subversion ou CVS, vous devez
l’obtenir avec git clone, svn co ou cvs co et la compresser
vous-même au format tar+gzip avec l'option --exclude-vcs.
Si les sources du programme sont disponibles dans un autre format
d'archive (par exemple, le programme se termine par .Z ou .zip ^
[9]), vous devriez le décompresser à l'aide des outils adéquats
et le recompresser.
Si le programme est distribué avec du contenu non compatible avec
les principes du logiciel libre selon Debian, vous devriez aussi
le décompresser pour enlever ce contenu et le recompresser avec
une version amont modifiée contenant dfsg.
Comme exemple, le programme nommé gentoo (un gestionnaire de
fichiers utilisant GTK+) sera utilisé. ^[10]
Créez un sous-répertoire dans votre répertoire personnel nommé
debian ou deb ou quoi que ce soit d'adéquat (par exemple le nom
du programme, ~/gentoo, ferait l'affaire dans ce cas). Placez
l'archive téléchargée dedans, et décompressez-la avec tar xzf
gentoo-0.9.12.tar.gz. Assurez-vous qu'aucun message
d'avertissement ne se produit, même sans importance, sinon les
outils de décompression d'autres personnes pourraient ne pas
gérer ces problèmes, et être incapables de les décompresser. La
ligne de commande de votre interpréteur devrait ressembler à
ceci :
$ mkdir ~/gentoo ; cd ~/gentoo
$ wget http://www.example.org/gentoo-0.9.12.tar.gz
$ tar xvzf gentoo-0.9.12.tar.gz
$ ls -F
gentoo-0.9.12/
gentoo-0.9.12.tar.gz
Maintenant vous avez un autre sous-répertoire, nommé
gentoo-0.9.12. Allez dans ce répertoire et lisez attentivement la
documentation fournie. Il s'agit généralement de fichiers nommés
README*, INSTALL*, *.lsm ou *.html. Vous devez trouver les
instructions pour compiler et installer le programme (elles
supposent très probablement que vous voulez l'installer dans le
répertoire /usr/local/bin ; ce n'est pas le cas, mais ce point
sera traité plus tard en Section 3.3, « Installation des fichiers
à leur emplacement »).
Vous devriez commencer la création du paquet avec un répertoire
source complètement propre (originel), ou simplement avec les
sources fraîchement décompressées.
2.4. Systèmes de construction simples
Des programmes simples sont généralement fournis avec un fichier
Makefile et peuvent être compilés en appelant simplement make. ^
[11] Certains d'entre eux gèrent make check, qui exécute des
vérifications internes. L'installation dans les répertoires de
destination se fait normalement avec make install.
Maintenant, essayez de compiler et d'exécuter le programme, pour
vous assurer qu'il fonctionne correctement et ne casse rien
d'autre quand il est installé ou utilisé.
Sachez aussi que vous pouvez généralement utiliser make clean (ou
mieux, make distclean) pour nettoyer le répertoire de
compilation. Parfois, make uninstall peut être utilisé pour
retirer tous les fichiers installés.
2.5. Systèmes de construction portables répandus
De nombreux logiciels libres sont écrits en C et C++. Beaucoup
d'entre eux utilisent les Autotools ou CMake pour les rendre
portables sur différentes architectures. Ces outils de
construction doivent être utilisés pour créer les Makefile et
d'autres fichiers sources nécessaires. Ensuite, de tels
programmes sont construits en utilisant l'habituel make; make
install.
Les Autotools sont les outils de construction GNU. Ils
comprennent Autoconf, Automake, Libtool et gettext. Vous pouvez
reconnaître de telles sources à l'aide des fichiers configure.ac,
Makefile.am et Makefile.in. ^[12]
La première étape du travail des Autotools est généralement faite
par les auteurs amont qui exécutent autoreconf -i -f dans le
répertoire des sources et distribuent les fichiers créés avec les
sources.
configure.ac-----+-> autoreconf -+-> configure
Makefile.am -----+ | +-> Makefile.in
src/Makefile.am -+ | +-> src/Makefile.in
| +-> config.h.in
automake
aclocal
aclocal.m4
autoheader
Modifier les fichiers configure.ac et Makefile.am nécessite un
peu de connaissance de autoconf et automake. Consultez info
autoconf et info automake.
La deuxième étape du travail des Autotools est habituellement que
les utilisateurs se procurent ces sources et exécutent ./
configure && make dans le répertoire des sources pour compiler le
programme en une commande exécutable binaire.
Makefile.in -----+ +-> Makefile -----+-> make -> binaire
src/Makefile.in -+-> ./configure -+-> src/Makefile -+
config.h.in -----+ +-> config.h -----+
|
config.status -+
config.guess --+
Vous pouvez modifier plein de choses dans le fichier Makefile ;
vous pouvez, par exemple, modifier l'emplacement par défaut du
répertoire d'installation en utilisant la commande ./configure
--prefix=/usr.
Bien que ce ne soit pas nécessaire, mettre à jour configure et
les autres fichiers avec autoreconf -i -f peut améliorer la
compatibilité des sources. ^[13]
CMake est un système de construction alternatif. De tels sources
peuvent être reconnus avec le fichier CMakeLists.txt.
2.6. Nom et version de paquet
Si le code source amont est distribué sous le nom de
gentoo-0.9.12.tar.gz, vous pouvez prendre gentoo comme nom de
paquet (source) et 0.9.12 comme version amont. Ces désignations
seront aussi utilisées dans le fichier debian/changelog décrit
plus loin dans Section 4.3, « changelog ».
Même si cette simple approche fonctionne la plupart du temps,
vous pourriez devoir remplacer nom de paquet et version amont en
renommant les sources amont afin de suivre la Charte Debian et
les conventions existantes.
Le nom de paquet ne doit contenir que des lettres minuscules
(a-z), des chiffres (0-9), les signes plus (+) ou moins (-) et
des points (.). Il doit comporter au moins deux caractères,
commencer par un caractère alphanumérique et ne doit pas être
déjà utilisé. Il est préférable de garder sa longueur inférieure
à trente caractères. ^[14]
Si l'amont utilise quelques termes génériques comme test-suite
comme nom, il vaut mieux les renommer pour identifier son contenu
de façon explicite et éviter de polluer l'espace de noms. ^[15]
La version amont ne devrait contenir que des caractères
alphanumériques (0-9A-Za-z), plus (+), tildes (~) et points (.).
Elle doit commencer par un chiffre (0-9). ^[16] Il est conseillé
de garder sa longueur inférieure à huit caractères si possible. ^
[17]
Si l'amont n'utilise pas un système d'affectation de version
classique comme 2.30.32 mais utilise plutôt une sorte de date
comme 11Apr29, un nom de code aléatoire ou une somme de hachage
d'un système de gestion de versions dans la version, assurez-vous
d'enlever ces parties de la version amont. Ces renseignements
peuvent être enregistrés dans le fichier debian/changelog. Si
vous devez inventer une version, utilisez le format AAAAMMJJ, par
exemple 20110429, comme numéro de version. Cela garantit que dpkg
interprète correctement les futures versions comme des mises à
niveau. Pour permettre des mises à niveau en douceur vers un
schéma de version classique comme 0.1 dans l'avenir, utilisez
plutôt la forme 0~AAMMJJ comme 0~110429 pour la version amont.
Les chaînes de version ^[18] peuvent être comparées en utilisant
dpkg(1) comme suit :
$ dpkg --compare-versions ver1 op ver2
La règle de comparaison de versions peut être résumée par :
* les chaînes sont comparées en commençant par le début ;
* les lettres sont plus grandes que les nombres ;
* les nombres sont comparés comme des entiers ;
* les lettres sont comparées dans l'ordre de leur code ASCII ;
* des règles particulières sont appliquées pour les points (.),
plus (+) et tildes (~) comme suit :
0.0 < 0.5 < 0.10 < 0.99 < 1 < 1.0~rc1 < 1.0 < 1.0+b1 <
1.0+nmu1 < 1.1 < 2.0
Un cas délicat se produit quand une version amont
gentoo-0.9.12-ReleaseCandidate-99.tar.gz est publiée comme une
préversion de gentoo-0.9.12.tar.gz. Vous devez vous assurer que
la mise à niveau fonctionne correctement en renommant les sources
amont en gentoo-0.9.12~rc99.tar.gz.
2.7. Configuration de dh_make
Configurez les variables d'environnement de l'interpréteur de
commandes $DEBEMAIL et $DEBFULLNAME de telle sorte que plusieurs
outils de maintenance Debian identifient l’adresse électronique
et le nom à utiliser pour les paquets : ^[19]
$ cat >>~/.bashrc <<EOF
DEBEMAIL="your.email.address@example.org"
DEBFULLNAME="Prénom Nom"
export DEBEMAIL DEBFULLNAME
EOF
$ . ~/.bashrc
2.8. Paquet Debian non natif initial
Les paquets Debian normaux sont des paquets Debian non natifs
réalisés à partir de programmes amont. Pour créer un paquet
Debian non natif à partir d'une source amont
gentoo-0.9.12.tar.gz, vous pouvez lui créer un paquet Debian non
natif initial en appelant la commande dh_make comme suit :
$ cd ~/gentoo
$ wget http://www.example.org/gentoo-0.9.12.tar.gz
$ tar xvzf gentoo-0.9.12.tar.gz
$ cd gentoo-0.9.12
$ dh_make -f ../gentoo-0.9.12.tar.gz
Bien sûr, remplacez le nom de fichier par celui de votre archive
source d'origine. ^[20] Consultez dh_make(8) pour plus de
précisions.
Vous devriez voir quelques questions sur le type de paquet vous
voulez créer. Gentoo est un paquet binaire simple — il ne crée
qu'un paquet binaire, c'est-à-dire un seul fichier .deb — donc la
première option sera sélectionnée (avec la touche s). Une fois
l'information vérifiée sur l'écran, confirmez en pressant Entrée.
^[21]
Cette exécution de dh_make crée une copie de l'archive amont en
gentoo_0.9.12.orig.tar.gz dans le répertoire parent pour
permettre ensuite la création d'un paquet source Debian non natif
nommé debian.tar.gz plus tard :
$ cd ~/gentoo ; ls -F
gentoo-0.9.12/
gentoo-0.9.12.tar.gz
gentoo_0.9.12.orig.tar.gz
Veuillez remarquer deux caractéristiques du nom de fichier
gentoo_0.9.12.orig.tar.gz :
* le nom de paquet et la version sont séparés par le caractère
tiret bas (_) ;
* la chaîne .orig est insérée avant le .tar.gz.
Vous devriez aussi remarquer que de nombreux fichiers modèles
sont créés dans les sources sous le répertoire debian. Ce sera
expliqué en Chapitre 4, Fichiers nécessaires dans le répertoire
debian et Chapitre 5, Autres fichiers dans le répertoire debian.
Vous devriez aussi comprendre que l'empaquetage ne peut pas être
un processus complètement automatisé. Vous aurez à modifier les
sources amont pour Debian (consultez Chapitre 3, Modification du
code source). Après cela, vous devez utiliser les méthodes
correctes pour construire les paquets Debian (Chapitre 6,
Construction du paquet), les vérifier (Chapitre 7, Contrôle des
erreurs du paquet) et les envoyer (Chapitre 9, Envoi de paquet).
Toutes ces étapes seront expliquées.
Si vous effacez par mégarde quelques fichiers modèles en
travaillant dessus, vous pouvez les retrouver en exécutant de
nouveau dh_make avec l'option --addmissing dans une arborescence
de paquet Debian.
La mise à jour d'un paquet existant peut devenir compliquée
puisqu'il pourrait utiliser d'anciennes techniques. Lors de
l'apprentissage des bases, veuillez vous en tenir aux cas
d'empaquetage récents ; des explications sont données plus loin
en Chapitre 8, Mise à jour de paquet.
Veuillez noter que le fichier source ne doit pas forcément
contenir de système de construction comme en Section 2.4,
« Systèmes de construction simples » et Section 2.5, « Systèmes
de construction portables répandus ». Il peut simplement s'agir
d'un ensemble de données graphiques par exemple. L'installation
de fichiers peut être effectuée en utilisant juste les fichiers
de configuration de debhelper comme debian/install (consultez
Section 5.11, « install »).
---------------------------------------------------------------------
^[4] Les paquets source Debian non natifs au style plus ancien de
format 1.0 utilisent à la place paquet_version-révision.diff.gz.
^[5] Consultez 5.6.1 « Source », 5.6.7 « Paquet » et
5.6.12 « Version ». L'architecture du paquet doit suivre la
Charte Debian, 5.6.8 « Architecture » et est automatiquement
attribuée par le processus de construction du paquet.
^[6] Consultez la référence du Développeur Debian
5.9.5 « Adoption de paquet ».
^[7] Cela dit, il existera toujours des paquets qui vaudront la
peine d'être empaquetés.
^[8] Ne vous inquiétez pas du Makefile manquant. Vous pouvez
installer la commande hello en utilisant simplement debhelper
comme en Section 5.11, « install », ou en modifiant le source
amont pour ajouter un nouveau Makefile avec la cible install
comme en Chapitre 3, Modification du code source.
^[9] Vous pouvez identifier le format de l'archive en utilisant
la commande file si l'extension du fichier ne suffit pas.
^[10] Ce programme est déjà empaqueté. La version actuelle
utilise Autotools comme structure de construction et est
substantiellement différente des exemples suivants qui étaient
basés sur la version 0.9.12.
^[11] Beaucoup de programmes récents sont livrés avec un script
appelé configure qui crée un fichier Makefile personnalisé pour
le système au moment de son exécution.
^[12] Les Autotools sont trop importants pour être traités dans
ce petit tutoriel. Cette section a seulement pour but de fournir
les mots-clefs et les références. Veuillez vous assurer d'avoir
lu le tutoriel des Autotools et la copie locale de /usr/share/doc
/autotools-dev/README.Debian.gz si vous avez besoin de les
utiliser.
^[13] Vous pouvez automatiser ce processus en utilisant le paquet
dh-autoreconf. Consultez Section 4.4.3, « Personnalisation du
fichier rules ».
^[14] La longueur par défaut du champ de nom de paquet dans
aptitude est de 30 caractères. Plus de 90 % des paquets ont un
nom de paquet inférieur à 24 caractères.
^[15] Si vous suivez la référence du Développeur Debian
5.1. « Nouveaux paquets », le processus d'ITP devrait permettre
de se rendre compte de ce genre de problème.
^[16] Cette règle plus stricte devrait permettre d'éviter toute
confusion de noms de fichier.
^[17] La longueur par défaut du champ de version dans aptitude
est de 10 caractères. La révision Debian précédée par un tiret en
utilise au moins 2. Plus de 80 % des paquets ont une version
amont inférieure à 8 caractères et une révision Debian inférieure
à 2 caractères. Plus de 90 % des paquets ont une version amont
inférieure à 10 caractères et une révision Debian inférieure à
3 caractères.
^[18] Les chaînes de version peuvent être version amont (version
), révision Debian (révision) ou version (version-révision).
Consultez Section 8.1, « Nouvelle révision Debian » pour la façon
dont la révision Debian est incrémentée.
^[19] Le texte qui suit présuppose que l'interpréteur de
commandes que vous utilisez à la connexion est Bash. Si vous
utilisez un autre interpréteur de commandes, par exemple zsh, il
est nécessaire d'utiliser le fichier de configuration
correspondant au lieu de ~/.bashrc.
^[20] Si les sources amont fournissent le répertoire debian et
son contenu, exécutez la commande dh_make avec l'option
supplémentaire --addmissing. Le nouveau format source 3.0 (quilt)
est suffisamment robuste pour ne pas casser même avec ces
paquets. Vous pourriez avoir besoin de mettre à jour le contenu
fourni par la version amont pour votre paquet Debian.
^[21] Il y a plusieurs choix à ce moment : s pour un seul paquet
binaire, i pour un paquet binaire indépendant de l'architecture,
m pour plusieurs paquets binaires, l pour un paquet de
bibliothèque, k pour un paquet de module du noyau, n pour un
paquet de correctif du noyau et b pour un paquet cdbs. Ce
document se concentre sur l'utilisation de la commande dh (du
paquet debhelper) pour créer un seul paquet binaire, mais
effleure aussi son utilisation pour les paquets binaires
indépendants de l'architecture ou de plusieurs paquets binaires.
Le paquet cdbs propose une autre infrastructure de scripts de
paquet que la commande dh et sort du cadre de ce document.
Chapitre 3. Modification du code source
La réécriture de ce tutoriel avec des contenus à jour et des
exemples pratiques supplémentaires est disponible sur Guide du
responsable Debian. Veuillez utiliser ce nouveau tutoriel comme
document principal.
La place manque pour entrer dans tous les détails de modification
des sources amont, mais voici quelques étapes basiques et
quelques problèmes créant des difficultés.
3.1. Configuration de quilt
Le programme quilt fournit une méthode fondamentale pour
enregistrer les modifications du code source amont pour
l'empaquetage Debian. Il est utile d'avoir de légères
personnalisations du paramétrage par défaut, configurez donc un
alias dquilt pour l'empaquetage Debian en ajoutant les lignes
suivantes à ~/.bashrc. La deuxième ligne fournit les mêmes
fonctionnalités de complétion de l’interpréteur pour la commande
dquilt que pour la commande quilt :
alias dquilt="quilt --quiltrc=${HOME}/.quiltrc-dpkg"
. /usr/share/bash-completion/completions/quilt
complete -F _quilt_completion -o filenames dquilt
Ensuite créez ~/.quiltrc-dpkg comme suit :
d=. ; while [ ! -d $d/debian -a $(readlink -e $d) != / ]; do d=$d/..; done
if [ -d $d/debian ] && [ -z $QUILT_PATCHES ]; then
# if in Debian packaging tree with unset $QUILT_PATCHES
QUILT_PATCHES="debian/patches"
QUILT_PATCH_OPTS="--reject-format=unified"
QUILT_DIFF_ARGS="-p ab --no-timestamps --no-index --color=auto"
QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index"
QUILT_COLORS="diff_hdr=1;32:diff_add=1;34:diff_rem=1;31:diff_hunk=1;33:diff_ctx=35:diff_cctx=33"
if ! [ -d $d/debian/patches ]; then mkdir $d/debian/patches; fi
fi
Consultez quilt(1) et /usr/share/doc/quilt/quilt.pdf.gz pour
apprendre à utiliser quilt.
3.2. Correction de bogues amont
Si vous trouvez une erreur dans le Makefile amont comme suit, où
install: gentoo aurait dû être install: gentoo-target :
install: gentoo
install ./gentoo $(BIN)
install icons/* $(ICONS)
install gentoorc-example $(HOME)/.gentoorc
Corrigez l'erreur et enregistrez-la avec la commande dquilt sous
fix-gentoo-target.patch : ^[22]
$ mkdir debian/patches
$ dquilt new fix-gentoo-target.patch
$ dquilt add Makefile
Modifiez le fichier Makefile comme suit :
install: gentoo-target
install ./gentoo $(BIN)
install icons/* $(ICONS)
install gentoorc-example $(HOME)/.gentoorc
Demandez à dquilt de créer debian/patches/fix-gentoo-target.patch
et ajoutez sa description conformément à DEP-3 : Directives pour
l'étiquetage des correctifs :
$ dquilt refresh
$ dquilt header -e
... description du correctif
3.3. Installation des fichiers à leur emplacement
La plupart des logiciels tiers s'installent d'eux-mêmes dans le
répertoire /usr/local. Dans Debian, il est réservé à l'usage
privé de l'administrateur système, les paquets ne doivent donc
pas utiliser de répertoires comme /usr/local/bin, mais devraient
plutôt utiliser les répertoires système comme /usr/bin,
conformément à la norme de hiérarchie des fichiers (FHS).
Habituellement, make(1) est utilisé pour automatiser la
construction du programme et l'exécution de make install installe
les programmes directement à l'endroit voulu (d'après la cible
install du Makefile). Pour permettre à Debian de fournir des
paquets installables préconstruits, il modifie le système de
construction pour installer les programmes dans une image de
l'arborescence de fichiers créée dans un répertoire temporaire
plutôt que dans la destination réelle.
Ces deux différences entre l'installation normale du programme
d'un côté et le système d'empaquetage Debian de l'autre peuvent
être abordées de façon transparente par le paquet debhelper à
l'aide des commandes dh_auto_configure et dh_auto_install si les
conditions suivantes sont vérifiées :
* le Makefile doit suivre les conventions GNU et gérer la
variable $(DESTDIR) ; ^[23]
* les sources doivent suivre la norme de hiérarchie des
fichiers (« Filesystem Hierarchy Standard » ou FHS).
Les programmes qui utilisent GNU autoconf suivent les conventions
GNU automatiquement, de telle sorte qu'ils peuvent être faciles à
empaqueter. Sur cette base et d'autres paramètres, on estime que
le paquet debhelper fonctionnera pour 90 % des paquets sans
modification intrusive de leur système de construction.
L'empaquetage n'est donc pas aussi compliqué qu'il n'y paraît.
Si vous devez modifier le Makefile, vous devriez vous assurer
qu'il gère la variable $(DESTDIR). Bien qu'elle ne soit pas
configurée par défaut, la variable $(DESTDIR) précède chaque
chemin de fichier utilisé par le programme d'installation. Le
script d'empaquetage configurera $(DESTDIR) en tant que
répertoire temporaire.
Pour un paquet source créant un seul paquet binaire, le
répertoire temporaire utilisé par la commande dh_auto_install
sera configuré en debian/paquet. ^[24] Le contenu du répertoire
temporaire sera copié sur le système de l'utilisateur qui
installera votre paquet, la seule différence est que dpkg placera
ces fichiers dans des chemins relatifs au répertoire racine
plutôt qu'au répertoire de travail.
Gardez à l'esprit que même si le programme s'installe dans debian
/paquet, il doit continuer à s'exécuter correctement quand il est
installé à partir du paquet .deb sous le répertoire racine. Vous
ne devez donc pas laisser le système de construction coder en dur
des chaînes de caractères comme /home/moi/deb/paquet-version/usr/
share/paquet dans les fichiers du paquet.
Voici les parties concernées du Makefile de gentoo ^[25] :
# Emplacement des commandes exécutables lors de « make install »
BIN = /usr/local/bin
# Emplacement des icônes lors de « make install »
ICONS = /usr/local/share/gentoo
Les fichiers sont configurés pour s'installer sous /usr/local/.
Conformément aux explications précédentes, ce répertoire est
réservé pour les utilisations locales de Debian, changez donc ces
chemins comme suit :
# Emplacement des commandes exécutables lors de « make install »
BIN = $(DESTDIR)/usr/bin
# Emplacement des icônes lors de « make install »
ICONS = $(DESTDIR)/usr/share/gentoo
Les emplacements exacts qui devraient être utilisés pour les
exécutables, icônes, documentation, etc., sont décrits dans la
norme de hiérarchie des fichiers (FHS). Vous devriez la consulter
et lire les sections relatives à votre paquet.
Dès lors, les commandes exécutables devraient être installées
sous /usr/bin plutôt que sous /usr/local/bin, la page de manuel
sous /usr/share/man/man1 plutôt que sous /usr/local/man/man1 et
ainsi de suite. Remarquez qu'il n'y a pas de page de manuel
mentionnée dans le fichier Makefile de gentoo, mais comme la
Charte Debian exige que chaque programme en ait une, il faudra en
créer une plus tard et l'installer dans /usr/share/man/man1.
Certains programmes n'utilisent pas les variables des fichiers
Makefile pour définir des chemins comme ci-dessus. Cela signifie
que vous risquez de devoir modifier de vrais fichiers sources C
pour qu'ils utilisent les emplacements corrects. Mais où, et que
chercher exactement ? Vous pouvez le découvrir avec :
$ grep -nr --include='*.[c|h]' -e 'usr/local/lib' .
grep va parcourir récursivement l'arbre des sources et donner le
nom des fichiers et le numéro des lignes où il trouve une
occurrence.
Modifiez ces fichiers en remplaçant dans ces lignes, usr/local/
lib par usr/lib. Cela peut être automatisé comme suit :
$ sed -i -e 's#usr/local/lib#usr/lib#g' \
$(find . -type f -name '*.[c|h]')
Afin de confirmer toutes les substitutions, vous pouvez procéder
de façon interactive comme suit :
$ vim '+argdo %s#usr/local/lib#usr/lib#gce|update' +q \
$(find . -type f -name '*.[c|h]')
Ensuite, vous devriez trouver la cible install (chercher la ligne
qui commence par install: fonctionne en général) et renommez
toutes les références aux répertoires autres que ceux définis au
début du Makefile.
À l'origine, la cible install de gentoo était de la forme :
install: gentoo-target
install ./gentoo $(BIN)
install icons/* $(ICONS)
install gentoorc-example $(HOME)/.gentoorc
Corrigez ce bogue amont et enregistrez la modification avec la
commande dquilt sous debian/patches/install.patch :
$ dquilt new install.patch
$ dquilt add Makefile
Dans votre éditeur, modifiez cela pour le paquet Debian comme
suit :
install: gentoo-target
install -d $(BIN) $(ICONS) $(DESTDIR)/etc
install ./gentoo $(BIN)
install -m644 icons/* $(ICONS)
install -m644 gentoorc-example $(DESTDIR)/etc/gentoorc
Vous aurez remarqué qu'il y a maintenant une commande install -d
avant les autres dans la règle. Elle n'existait pas dans le
Makefile d'origine parce qu'habituellement /usr/local/bin et les
autres répertoires existent déjà sur le système dans lequel make
install est exécuté. Cependant, puisque dans notre cas
l'installation se fait dans une arborescence spécifique
nouvellement créée, chacun de ces répertoires doit être créé.
D'autres choses peuvent être ajoutées à la fin de la règle, comme
l'installation de la documentation additionnelle que l'auteur
amont oublie parfois :
install -d $(DESTDIR)/usr/share/doc/gentoo/html
cp -a docs/* $(DESTDIR)/usr/share/doc/gentoo/html
Vérifiez soigneusement, et si tout est bon, demandez à dquilt de
créer le correctif debian/patches/install.patch et ajoutez sa
description :
$ dquilt refresh
$ dquilt header -e
... description du correctif
Vous avez maintenant un ensemble de correctifs.
1. Correction d'un bogue amont : debian/patches/
fix-gentoo-target.patch ;
2. Modification spécifique à l'empaquetage Debian : debian/
patches/install.patch.
Chaque fois que vous faites des modifications qui ne sont pas
spécifiques à Debian comme debian/patches/
fix-gentoo-target.patch, envoyez-les au responsable amont pour
qu'elles puissent être intégrées dans la version suivante du
programme et que tout le monde puisse en profiter. Évitez aussi
de faire des corrections spécifiques à Debian ou Linux — ou même
UNIX ! Faites-les portables. Cela rendra vos corrections beaucoup
plus faciles à appliquer.
Remarquez que vous ne devez pas envoyer les fichiers debian/* en
amont.
3.4. Bibliothèques différentes
Il y a un autre problème courant : les bibliothèques sont souvent
différentes d'une plate-forme à l'autre. Par exemple, Makefile
peut contenir une référence à une bibliothèque qui n'existe pas
sur le système Debian. Dans ce cas, remplacez-la par une
bibliothèque qui existe dans Debian, et qui sert à la même chose.
Supposons qu'une ligne de Makefile (ou Makefile.in) du programme
comme suit :
LIBS = -ltruc -lbidule
Si votre programme ne compile pas depuis que la bibliothèque truc
n'existe plus et que son équivalent est fourni par la
bibliothèque truc2 sur le système Debian, vous pouvez corriger ce
problème de construction en debian/patches/truc2.patch en
modifiant truc en truc2 : ^[26]
$ dquilt new truc2.patch
$ dquilt add Makefile
$ sed -i -e 's/-ltruc/-ltruc2/g' Makefile
$ dquilt refresh
$ dquilt header -e
... description du correctif
---------------------------------------------------------------------
^[22] Le répertoire debian/patches devrait maintenant exister si
vous avez exécuté dh_make comme décrit auparavant. Cet exemple de
manipulation le crée seulement si vous mettez à jour un paquet
existant.
^[23] Consultez les normes GNU de codage : 7.2.4 DESTDIR : prise
en charge des installations détournées.
^[24] Pour un paquet source créant plusieurs paquets binaires, la
commande dh_auto_install utilise debian/tmp comme répertoire
temporaire alors que la commande dh_install, à l'aide des
fichiers debian/paquet-1.install et debian/paquet-2.install,
séparera le contenu de debian/tmp dans les répertoires
temporaires debian/paquet-1 et debian/paquet-2 pour créer les
paquets binaires paquet-1_*.deb et paquet-2_*.deb
^[25] Il s'agit simplement d'un exemple pour montrer à quoi le
Makefile devrait ressembler. Si le Makefile est créé par la
commande ./configure, la bonne façon de modifier ce genre de
Makefile est d'exécuter ./configure à partir de la commande
dh_auto_configure avec les options par défaut y compris --prefix=
/usr.
^[26] Si des modifications de l'API existent entre les
bibliothèques truc et truc2, les modifications nécessaires au
code source doivent être faites pour correspondre à la nouvelle
API.
Chapitre 4. Fichiers nécessaires dans le répertoire debian
La réécriture de ce tutoriel avec des contenus à jour et des
exemples pratiques supplémentaires est disponible sur Guide du
responsable Debian. Veuillez utiliser ce nouveau tutoriel comme
document principal.
Un nouveau sous-répertoire se trouve dans le répertoire des
sources du programme, nommé debian. Certains fichiers de ce
répertoire sont à modifier pour personnaliser le comportement du
paquet. Les plus importants sont control, changelog, copyright et
rules, ils sont nécessaires pour tous les paquets. ^[27]
4.1. control
Ce fichier contient plusieurs valeurs utilisées par dpkg, dselect
, apt-get, apt-cache, aptitude et d'autres outils de gestion de
paquets pour gérer le paquet. Cela est défini par la Charte
Debian, 5 « Fichiers de contrôle et leurs champs ».
Le fichier control créé par dh_make ressemble à :
1 Source: gentoo
2 Section: unknown
3 Priority: extra
4 Maintainer: Prénom Nom <votre.adresse.mail@example.org>
5 Build-Depends: debhelper (>=10)
6 Standards-Version: 3.9.4
7 Homepage: <URL amont, si pertinente>
8
9 Package: gentoo
10 Architecture: any
11 Depends: ${shlibs:Depends}, ${misc:Depends}
12 Description: <description courte de 60 caractères au maximum>
13 <description longue, indentée par des espaces>
(Les numéros de ligne ont été ajoutés.)
Les lignes 1 à 7 sont les informations de contrôle pour le paquet
source. Les lignes 9 à 13 sont les informations de contrôle pour
le paquet binaire.
La ligne 1 est le nom du paquet source.
La ligne 2 est la section de la distribution à laquelle ce paquet
appartient.
Comme vous avez pu le constater, l'archive Debian est divisée en
plusieurs parties : main (logiciels libres), non-free (logiciels
non libres), et contrib (logiciels libres qui dépendent de
logiciels non libres). Chacune d'entre elles est divisée en
sections qui classent les paquets en catégories grossières. Entre
autres existent admin pour les programmes destinés aux
administrateurs, devel pour les outils de programmation, doc pour
la documentation, libs pour les bibliothèques, mail pour les
lecteurs et les démons de courrier électronique, net pour les
applications et démons de réseau, x11 pour les programmes X11 qui
ne conviennent pas mieux ailleurs, et bien d'autres. ^[28]
Changez la section en x11 (le préfixe main/ est implicite, et
peut donc être omis).
La ligne 3 décrit l'importance pour l'utilisateur d'installer ce
paquet : ^[29]
* la priorité optional fonctionne habituellement pour les
nouveaux paquets qui ne sont pas en conflit avec d'autres se
réclamant de priorité required, important ou standard.
Les sections et les priorités sont utilisées par des interfaces
comme aptitude quand elles trient les paquets et sélectionnent
les valeurs par défaut. Quand vous enverrez le paquet dans
Debian, les valeurs de ces deux champs peuvent être modifiées par
les responsables des archives, auquel cas vous serez notifié par
courrier.
Comme c'est un paquet de priorité normale et qu'il n'entre pas en
conflit avec quoi que ce soit, il suffit de laisser la priorité à
optional.
La ligne 4 est le nom et l'adresse électronique du responsable.
Assurez-vous que ce champ contient un en-tête To valable pour un
courrier électronique, car après l'envoi du paquet, le système de
suivi des bogues l'utilisera pour vous distribuer les courriers
relatifs aux bogues. Évitez d'utiliser les virgules, esperluettes
(&) ou parenthèses.
La ligne 5 contient la liste des paquets nécessaires pour
construire le paquet dans le champ Build-Depends. Le champ
Build-Depends-Indep peut-être ajouté dans une ligne
supplémentaire. ^[30] Certains paquets comme gcc ou make sont
implicites, puisqu'ils dépendent de build-essential. Si d'autres
outils sont nécessaires pour construire le paquet, vous devez les
ajouter à ces champs. Les multiples éléments sont séparés par des
virgules ; lisez ci-après les explications sur les dépendances
entre paquets binaires pour mieux comprendre la syntaxe de ces
lignes :
* pour tous les paquets empaquetés avec la commande dh dans le
fichier debian/rules, debhelper (>=9) doit faire partie du
champ Build-Depends pour être conforme à la Charte Debian au
sujet de la cible clean ;
* les paquets source de paquets binaires avec Architecture: any
sont reconstruits par les empaqueteurs automatiques
(« autobuilder »). Puisque la procédure des serveurs
d'empaquetage automatique installe seulement les paquets
indiqués dans le champ Build-Depends avant d'exécuter debian/
rules build (consultez Section 6.2, « Serveurs d'empaquetage
automatique (« autobuilder ») »), ce champ Build-Depends doit
indiquer pratiquement tous les paquets nécessaires et
Build-Depends-Indep est rarement utilisé ;
* pour les paquets source de paquets binaires dont tous sont
Architecture: all, le champ Build-Depends-Indep peut indiquer
tous les paquets nécessaires à moins qu'ils ne soient déjà
indiqués dans le champ Build-Depends pour être conforme à la
Charte Debian au sujet de la cible clean.
En cas de doute, utilisez le champ Build-Depends pour être sûr. ^
[31]
Pour déterminer les paquets nécessaires à la construction,
exécutez la commande :
$ dpkg-depcheck -d ./configure
Pour déterminer manuellement les dépendances de construction
exactes pour /usr/bin/toto, exécutez :
$ objdump -p /usr/bin/toto | grep NEEDED
et pour chaque bibliothèque affichée, par exemple libtoto.so.6,
exécutez :
$ dpkg -S libtoto.so.6
Ajoutez ensuite simplement la version -dev de chaque paquet dans
le champ Build-Depends. Si vous utilisez ldd à cet effet, des
dépendances de bibliothèque indirectes seront indiquées,
introduisant un problème de dépendances de construction
excessives.
gentoo a aussi besoin de xlibs-dev, libgtk1.2-dev et libgl1.2-dev
pour être construit, ils doivent donc être ajoutés à côté de
debhelper.
La ligne 6 est la version de la Charte Debian que ce paquet
respecte, celle que vous lisez quand vous créez le paquet.
En ligne 7 vous pouvez indiquer l'URL de la page d'accueil du
programme amont.
La ligne 9 est le nom du paquet binaire. C'est d'ordinaire le
même que le nom du paquet source, mais ce n'est pas
nécessairement le cas.
La ligne 10 décrit les architectures pour lesquelles le paquet
binaire peut être compilé. Cette valeur est en général un des
suivantes en fonction du type de paquet binaire : ^[32]
* Architecture: any
+ le paquet binaire créé dépend de l'architecture, en
général dans un langage compilé ;
* Architecture: all
+ le paquet binaire créé est indépendant de l'architecture,
en général du texte, des images ou des scripts en langage
interprété.
La ligne 10 est laissée telle quelle car c'est écrit en C.
dpkg-gencontrol(1) indiquera la valeur d'architecture appropriée
pour chaque machine sur laquelle ce paquet source sera compilé.
Si le paquet est indépendant d'une architecture (par exemple, un
script shell ou Perl, ou un document), changez ce paramètre en
all, et lisez plus loin en Section 4.4, « rules » comment
utiliser la règle binary-indep au lieu de binary-arch pour
construire le paquet.
La ligne 11 montre une des caractéristiques les plus puissantes
du système de paquet Debian. Les paquets peuvent être liés entre
eux de plusieurs façons. Hormis Depends, les autres champs
décrivant ces relations sont Recommends, Suggests, Pre-Depends,
Breaks, Conflicts, Provides et Replaces.
Les outils de gestion de paquets se comportent d'ordinaire de la
même manière quand ils gèrent ces relations ; sinon, ce sera
précisé (consultez dpkg(8), dselect(8), apt(8), aptitude(1)
, etc.)
Voici une description simplifiée des relations entre paquets : ^
[33]
* Depends
le paquet ne sera pas installé sans que les paquets dont il
dépend ne soient installés. Utilisez-le si le programme ne
s'exécute absolument pas (ou cause des dégâts sérieux) si un
paquet particulier n'est pas présent ;
* Recommends
à utiliser pour les paquets qui ne sont pas vraiment
indispensables mais qui sont généralement utilisés avec le
programme. Lorsqu'un utilisateur installe le paquet, toutes
les interfaces devraient proposer d'installer les paquets
recommandés. aptitude et apt-get installent par défaut les
paquets recommandés avec le paquet (mais l'utilisateur peut
désactiver ce comportement). dpkg ignorera ce champ ;
* Suggests
à utiliser pour les paquets qui fonctionnent bien avec le
programme mais qui ne sont pas du tout indispensables.
Lorsqu'un utilisateur installe le programme, il ne lui sera
probablement pas proposé d'installer les paquets suggérés.
aptitude peut être configuré pour installer les paquets
suggérés avec le paquet mais ce n'est pas le comportement par
défaut. dpkg et apt-get ignoreront ce champ ;
* Pre-Depends
cela est plus fort que Depends. Le paquet ne sera pas
installé avant que les paquets dont il pré-dépend ne soient
installés et correctement configurés. Utilisez-le très
rarement et seulement après en avoir discuté sur la liste de
discussion debian-devel@lists.debian.org. Autrement dit : ne
l'utilisez pas du tout ; :-)
* Conflicts
le paquet ne sera pas installé tant que les paquets avec
lesquels il est en conflit n'aient été retirés. À utiliser si
le programme ne peut absolument pas fonctionner ou s'il cause
d'énormes problèmes quand un paquet particulier est présent ;
* Breaks
les paquets énumérés seront cassés une fois que le paquet ait
été installé. En général, une entrée Breaks indique qu'elle
s'applique aux versions antérieures à une certaine valeur. La
résolution de conflit se fait en utilisant des gestionnaires
de paquets de haut niveau pour généralement mettre à niveau
les paquets énumérés ;
* Provides
quand il y a plusieurs alternatives pour certains types de
paquets, des noms virtuels ont été définis. La liste complète
est disponible dans le fichier
virtual-package-names-list.txt.gz. À utiliser si le programme
fournit une fonction d'un paquet virtuel existant ;
* Replaces
à utiliser quand le programme remplace des fichiers d'un
autre paquet, ou remplace complètement un autre paquet
(utilisé en conjonction avec Conflicts). Les fichiers du
paquet nommé seront écrasés par les fichiers de votre paquet.
Tous ces champs ont une syntaxe uniforme. Il s'agit d'une liste
de paquets séparés par des virgules. Ces noms de paquets peuvent
aussi être une liste d'alternatives, séparées par des barres
verticales | (symbole tube ou « pipe »).
Le domaine d'application des champs peut être restreint à des
versions particulières de chaque paquet nommé. La restriction de
chaque paquet particulier est indiquée entre parenthèses après
son nom, et devrait contenir une relation dans la liste suivante
suivie par une valeur de numéro de version. Les relations
autorisées sont <<, <=, =, >= et >> (respectivement : strictement
plus petit, plus petit ou égal, exactement égal, plus grand ou
égal et strictement plus grand). Par exemple :
Depends: toto (>= 1.2), libbidule1 (= 1.3.4)
Conflicts: machin
Recommends: libmachin4 (>> 4.0.7)
Suggests: truc
Replaces: truc (<< 5), truc-toto (<= 7.6)
La dernière fonctionnalité à connaître est ${shlibs:Depends}, $
{perl:Depends}, ${misc:Depends}, etc.
dh_shlibdeps(1) calcule les dépendances à des bibliothèques
partagées pour les paquets binaires. Il crée une liste
d'exécutables ELF et de bibliothèques partagées trouvées pour
chaque paquet binaire. Cette liste est utilisée en remplacement
de ${shlibs:Depends}.
dh_perl(1) calcule les dépendances de Perl. Il crée une liste de
dépendances vers perl ou perlapi pour chaque paquet binaire.
Cette liste est utilisée en remplacement de ${perl:Depends}.
Certaines commandes de debhelper peuvent rendre le paquet créé
dépendant de paquets supplémentaires. Toutes ces commandes créent
une liste de paquets nécessaires pour chaque paquet binaire.
Cette liste est utilisée en remplacement de ${misc:Depends}.
dh_gencontrol(1) crée DEBIAN/control pour chaque paquet binaire
en substituant ${shlibs:Depends}, ${perl:Depends}, $
{misc:Depends}, etc.
Cela dit, le champ Depends peut rester exactement comme il est
maintenant, et une autre ligne avec Suggests: file peut être
ajoutée, car gentoo peut utiliser certaines fonctionnalités
fournies par le paquet file.
La ligne 9 est l'URL de la page d'accueil. Supposons qu'il
s'agisse de http://www.obsession.se/gentoo/.
La ligne 12 est la description courte. Les terminaux sont larges
de 80 colonnes par convention, aussi elle ne devrait pas dépasser
les 60 caractères. fully GUI-configurable, two-pane X file
manager convient ici.
À la ligne 13 commence la description longue. Celle-ci devrait
être un paragraphe qui donne plus de détails sur le paquet. La
colonne 1 de chaque ligne doit être vide. Il ne peut y avoir de
ligne vide, mais vous pouvez mettre un seul . (point) dans la
colonne 2 pour simuler une ligne vide. De plus, il ne peut pas y
avoir plus d'une ligne vide après la description longue. ^[34]
Le champ Vcs-* pour documenter le système de gestion de versions
(VCS) peut être inséré entre les lignes 6 et 7. ^[35] Considérons
que le paquet gentoo a son VCS localisé sur le service Git
d'Alioth en git://git.debian.org/git/collab-maint/gentoo.git.
Finalement, voici le fichier control mis à jour :
1 Source: gentoo
2 Section: x11
3 Priority: optional
4 Maintainer: Prénom Nom <votre.adresse.mail@example.org>
5 Build-Depends: debhelper (>=10), xlibs-dev, libgtk1.2-dev, libglib1.2-dev
6 Standards-Version: 4.0.0
7 Vcs-Git: https://anonscm.debian.org/git/collab-maint/gentoo.git
8 Vcs-browser: https://anonscm.debian.org/git/collab-maint/gentoo.git
9 Homepage: http://www.obsession.se/gentoo/
10
11 Package: gentoo
12 Architecture: any
13 Depends: ${shlibs:Depends}, ${misc:Depends}
14 Suggests: file
15 Description: fully GUI-configurable, two-pane X file manager
16 gentoo is a two-pane file manager for the X Window System. gentoo lets the
17 user do (almost) all of the configuration and customizing from within the
18 program itself. If you still prefer to hand-edit configuration files,
19 they're fairly easy to work with since they are written in an XML format.
20 .
21 gentoo features a fairly complex and powerful file identification system,
22 coupled to an object-oriented style system, which together give you a lot
23 of control over how files of different types are displayed and acted upon.
24 Additionally, over a hundred pixmap images are available for use in file
25 type descriptions.
26 .
29 gentoo was written from scratch in ANSI C, and it utilizes the GTK+ toolkit
30 for its interface.
(Les numéros de ligne ont été ajoutés.)
4.2. copyright
Ce fichier contient des renseignements sur le copyright et la
licence des sources amont. La Charte Debian, 12.5 « Informations
sur le copyright » impose son contenu et la DEP-5 : debian/
copyright analysable automatiquement fournit des directives pour
son format.
dh_make peut proposer un modèle de fichier copyright. L'option
--copyright gpl2 peut être utilisée ici pour obtenir un modèle de
fichier pour le paquet gentoo publié sous GPL-2.
You must fill in missing information to complete this file, such
as the place you got the package from, the actual copyright
notice, and the license. For certain common free software
licenses (GNU GPL-1, GNU GPL-2, GNU GPL-3, LGPL-2, LGPL-2.1,
LGPL-3, GNU FDL-1.2, GNU FDL-1.3, Apache-2.0, 3-Clause BSD,
CC0-1.0, MPL-1.1, MPL-2.0 or the Artistic license), you can just
refer to the appropriate file in the /usr/share/common-licenses/
directory that exists on every Debian system. Otherwise, you must
include the complete license.
En bref, voici ce à quoi le fichier copyright de gentoo devrait
ressembler :
1 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
2 Upstream-Name: gentoo
3 Upstream-Contact: Emil Brink <emil@obsession.se>
4 Source: http://sourceforge.net/projects/gentoo/files/
5
6 Files: *
7 Copyright: 1998-2010 Emil Brink <emil@obsession.se>
8 License: GPL-2+
9
10 Files: icons/*
11 Copyright: 1998 Johan Hanson <johan@tiq.com>
12 License: GPL-2+
13
14 Files: debian/*
15 Copyright: 1998-2010 Josip Rodin <joy-mg@debian.org>
16 License: GPL-2+
17
18 License: GPL-2+
19 This program is free software; you can redistribute it and/or modify
20 it under the terms of the GNU General Public License as published by
21 the Free Software Foundation; either version 2 of the License, or
22 (at your option) any later version.
23 .
24 This program is distributed in the hope that it will be useful,
25 but WITHOUT ANY WARRANTY; without even the implied warranty of
26 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
27 GNU General Public License for more details.
28 .
29 You should have received a copy of the GNU General Public License along
30 with this program; if not, write to the Free Software Foundation, Inc.,
31 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
32 .
33 On Debian systems, the full text of the GNU General Public
34 License version 2 can be found in the file
35 '/usr/share/common-licenses/GPL-2'.
(Les numéros de ligne ont été ajoutés.)
Veuillez suivre les indications fournies par les responsables de
l'archive et envoyées sur la liste debian-devel-announce : http:/
/lists.debian.org/debian-devel-announce/2006/03/msg00023.html.
4.3. changelog
C'est un fichier obligatoire, avec un format spécifique décrit
dans la Charte Debian, 4.4 « debian/changelog ». Ce format est
utilisé par dpkg et d'autres programmes pour obtenir le numéro de
version, de révision, de distribution et l'urgence de votre
paquet.
Pour vous, il est également important, puisqu'il est bon de
documenter toutes les modifications effectuées. Cela permettra
aux personnes qui téléchargent le paquet de voir s'il y a des
problèmes à connaître. Il sera conservé en /usr/share/doc/gentoo/
changelog.Debian.gz dans le paquet binaire.
dh_make en crée un par défaut, et il ressemble à ceci :
1 gentoo (0.9.12-1) unstable; urgency=medium
2
3 * Initial release. (Closes: #nnnn) <nnnn is the bug number of your ITP>
4
5 -- Josip Rodin <joy-mg@debian.org> Mon, 22 Mar 2010 00:37:31 +0100
6
(Les numéros de ligne ont été ajoutés.)
La ligne 1 contient le nom du paquet, la version, la distribution
et l'urgence. Le nom doit correspondre au nom du paquet source,
la distribution devrait être unstable, et l'urgence devrait être
en medium à moins qu’il n’existe une raison particulière pour une
autre valeur.
Les lignes 3 à 5 composent l'entrée de journal, où vous
documentez les modifications effectuées dans la révision du
paquet (pas les modifications amont — il y a un fichier spécial
pour cela, créé par les auteurs amont, que vous installerez comme
/usr/share/doc/gentoo/changelog.gz). Supposons que votre rapport
de bogue ITP (« Intent To Package » ou intention d'empaqueter)
avait pour numéro 12345. Les nouvelles lignes doivent être
insérées juste en dessous de la première ligne qui commence avec
une astérisque (*). Vous pouvez utiliser dch(1) pour le modifier.
Vous pouvez éditer cela manuellement avec un éditeur de texte à
condition de suivre les conventions de formatage utilisées par
dch(1).
Pour éviter d'envoyer un paquet accidentellement avant qu'il ne
soit terminé, il vaut mieux modifier la valeur de distribution à
UNRELEASED qui n'est pas valable.
Vous obtiendrez quelque chose comme :
1 gentoo (0.9.12-1) UNRELEASED; urgency=low
2
3 * Initial Release. Closes: #12345
4 * This is my first Debian package.
5 * Adjusted the Makefile to fix $(DESTDIR) problems.
6
7 -- Prénom Nom <votre.adresse.mail@example.org> Mon, 22 Mar 2010 00:37:31 +0100
8
(Les numéros de ligne ont été ajoutés.)
Une fois satisfait de toutes les modifications, correctement
documentées dans changelog, vous devriez modifier la valeur de
distribution d'UNRELEASED à la valeur de distribution cible
unstable (ou même experimental). ^[36]
Vous pouvez en apprendre plus sur la mise à jour du fichier
changelog plus loin en Chapitre 8, Mise à jour de paquet.
4.4. rules
Il faut maintenant examiner les règles utilisées par
dpkg-buildpackage(1) pour créer vraiment le paquet. Ce fichier
est en fait un autre Makefile, mais différent de ceux des sources
amont. Contrairement aux autres fichiers de debian, celui-ci est
marqué comme exécutable.
4.4.1. Cibles du fichier rules
Tous les fichiers rules, comme n'importe quel Makefile, sont
constitués de plusieurs règles, chacune d'entre elles définissant
une cible et comment la réaliser. ^[37] Une nouvelle règle
commence avec la déclaration de sa cible en première colonne. Les
lignes suivantes commençant par une tabulation (caractère
ASCII 9 : TAB) indiquent ce qui doit être réalisé pour cette
cible. Les lignes vides et celles qui commencent par dièse (#)
sont traitées comme des commentaires et sont ignorées. ^[38]
Une règle que vous voulez exécuter est appelée par le nom de sa
cible comme un argument de la ligne de commande. Par exemple
debian/rules build et fakeroot make -f debian/rules binary
exécutent respectivement les règles pour les cibles build et
binary.
Voici une explication simplifiée des cibles :
* clean (obligatoire) : pour nettoyer tous les fichiers
compilés, créés et inutiles de l'arborescence de
construction ;
* build (obligatoire) : pour construire les programmes compilés
et les documents formatés à partir des sources dans
l'arborescence de construction ;
* build-arch (obligatoire) : pour construire les programmes
compilés dépendants de l'architecture à partir des sources
dans l'arborescence de construction ;
* build-indep (obligatoire) : pour construire les documents
formatés indépendants de l'architecture à partir des sources
dans l'arborescence de construction ;
* install (optionnelle) : pour installer les fichiers dans
l'arborescence de chaque paquet binaire dans le répertoire
debian. Si elles existent, les cibles binary* dépendent en
réalité de cette cible.
* binary (obligatoire) : pour créer tous les paquets binaires
(en réalité, une combinaison des cibles binary-arch et
binary-indep) ; ^[39]
* binary-arch (obligatoire) : pour créer tous les paquets
binaires dépendants de l'architecture (Architecture: any)
dans le répertoire parent ;^[40]
* binary-indep (obligatoire) : pour créer tous les paquets
binaires indépendants de l'architecture (Architecture: all)
dans le répertoire parent ;^[41]
* get-orig-source (optionnelle) : pour obtenir la dernière
version du paquet source d'origine à partir d'une archive
amont.
Vous vous sentez sans doute submergé pour l'instant, mais les
choses vont vraiment se simplifier à l'examen du fichier rules
que dh_make donne par défaut.
4.4.2. Fichier rules par défaut
Les versions récentes de dh_make créent un fichier rules par
défaut très simple mais aussi très puissant en utilisant la
commande dh :
1 #!/usr/bin/make -f
2 # See debhelper(7) (uncomment to enable)
3 # output every command that modifies files on the build system.
4 #DH_VERBOSE = 1
5
6 # see FEATURE AREAS in dpkg-buildflags(1)
7 #export DEB_BUILD_MAINT_OPTIONS = hardening=+all
8
9 # see ENVIRONMENT in dpkg-buildflags(1)
10 # package maintainers to append CFLAGS
11 #export DEB_CFLAGS_MAINT_APPEND = -Wall -pedantic
12 # package maintainers to append LDFLAGS
13 #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
14
15
16 %:
17 dh $@
(Les numéros de ligne ont été ajoutés et certains commentaires
réduits. Dans le vrai fichier rules, l’espace de début est une
tabulation.)
Vous avez probablement l'habitude de la ligne 1 avec les scripts
shell et Perl. Cela signifie que ce fichier doit être exécuté par
/usr/bin/make.
La ligne 4 peut être décommentée pour configurer la variable
DH_VERBOSE à 1, afin que la commande dh affiche les commandes
dh_* qu'elle exécute. Vous pouvez également ajouter ici une ligne
export DH_OPTIONS=-v, afin que chaque commande dh_* affiche les
commandes qu'elle exécute. Cela permet de comprendre ce qui se
passe exactement derrière ce simple fichier rules, et de déboguer
ses problèmes. Ce nouveau dh est conçu pour constituer un élément
essentiel des outils debhelper sans rien vous cacher.
Lines 16 and 17 are where all the work is done with an implicit
rule using the pattern rule. The percent sign means "any
targets", which then call a single program, dh, with the target
name. ^[42] The dh command is a wrapper script that runs
appropriate sequences of dh_* programs depending on its argument.
^[43]
* debian/rules clean exécute dh clean, qui exécute à son tour :
dh_testdir
dh_auto_clean
dh_clean
* debian/rules build exécute dh build, qui exécute à son tour :
dh_testdir
dh_auto_configure
dh_auto_build
dh_auto_test
* fakeroot debian/rules binary exécute fakeroot dh binary, qui
exécute à son tour : ^[44]
dh_testroot
dh_prep
dh_installdirs
dh_auto_install
dh_install
dh_installdocs
dh_installchangelogs
dh_installexamples
dh_installman
dh_installcatalogs
dh_installcron
dh_installdebconf
dh_installemacsen
dh_installifupdown
dh_installinfo
dh_installinit
dh_installmenu
dh_installmime
dh_installmodules
dh_installlogcheck
dh_installlogrotate
dh_installpam
dh_installppp
dh_installudev
dh_installwm
dh_installxfonts
dh_bugfiles
dh_lintian
dh_gconf
dh_icons
dh_perl
dh_usrlocal
dh_link
dh_compress
dh_fixperms
dh_strip
dh_makeshlibs
dh_shlibdeps
dh_installdeb
dh_gencontrol
dh_md5sums
dh_builddeb
* fakeroot debian/rules binary-arch exécute fakeroot dh
binary-arch, qui exécute à son tour la même séquence que
fakeroot dh binary mais avec l'option -a ajoutée à chaque
commande ;
* fakeroot debian/rules binary-indep exécute fakeroot dh
binary-indep, qui exécute à son tour à peu près la même
séquence que fakeroot dh binary à l'exception de dh_strip,
dh_makeshlibs et dh_shlibdeps, et avec l'option -i ajoutée à
chaque commande restante.
Le rôle des commandes dh_* est presque évident d'après leur nom.
^[45] Les plus remarquables d'entre elles valent la peine d'être
(très) brièvement présentées de façon simplifiée, dans
l'hypothèse d'un environnement de construction basé sur un
Makefile : ^[46]
* dh_auto_clean exécute normalement ce qui suit si un Makefile
fournit la cible distclean : ^[47]
make distclean
* dh_auto_configure exécute normalement ce qui suit si ./configure
existe (les paramètres sont abrégés pour la lisibilité) :
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var ...
* dh_auto_build exécute normalement ce qui suit pour exécuter la
première cible de Makefile si elle existe :
make
* dh_auto_test exécute normalement ce qui suit si un Makefile
fournit la cible test : ^[48]
make test
* dh_auto_install exécute normalement ce qui suit si un Makefile
fournit la cible install (la ligne est coupée pour la lisibilité)
:
make install \
DESTDIR=/chemin/vers/paquet_version-révision/debian/paquet
Toutes les cibles ayant besoin de la commande fakeroot
contiendront dh_testroot, qui se terminera en erreur si vous
n'utilisez pas cette commande afin de vous faire passer pour le
superutilisateur.
Le plus important à propos du fichier rules créé par dh_make,
c'est qu'il ne s'agit que d'une suggestion. Il fonctionnera pour
la plupart des paquets, mais pour les plus compliqués, vous ne
devez pas hésiter à le modifier pour le faire correspondre à vos
besoins.
Bien que la cible install ne soit pas obligatoire, elle est prise
en charge. fakeroot dh install se comporte comme fakeroot dh
binary mais s'arrête après dh_fixperms.
4.4.3. Personnalisation du fichier rules
Il existe plusieurs façons de personnaliser le fichier rules créé
avec la nouvelle commande dh.
La commande dh $@ peut être personnalisée comme suit : ^[49]
* ajout de l'assistance pour la commande dh_python2 (la
meilleure solution pour Python) : ^[50]
+ ajout de python à Build-Depends,
+ utilisation de dh $@ --with python2,
+ conséquence : gestion des modules Python avec la
structure python ;
* ajout de l'assistance pour la commande dh_pysupport
(obsolète) :
+ ajout de python-support à Build-Depends,
+ utilisation de dh $@ --with pysupport,
+ conséquence : gestion des modules Python avec la
structure python-support ;
* ajout de l'assistance pour la commande dh_pycentral
(obsolète) :
+ ajout de python-central à Build-Depends,
+ utilisation de dh $@ --with python-central à la place,
+ conséquence : désactivation de la commande dh_pysupport,
+ conséquence : gestion des modules Python avec la
structure python-central ;
* ajout de l'assistance pour la commande dh_installtex :
+ ajout de tex-common à Build-Depends,
+ utilisation de dh $@ --with tex à la place,
+ conséquence : enregistrement des fontes de Type 1, des
modèles de césure et des formats avec TeX ;
* ajout de l'assistance pour les commandes dh_quilt_patch et
dh_quilt_unpatch :
+ ajout de quilt à Build-Depends,
+ utilisation de dh $@ --with quilt à la place,
+ conséquence : application et retrait des correctifs au
code source amont à partir des fichiers du répertoire
debian/patches pour les paquets source au format 1.0,
+ inutile pour les paquets source au format 3.0 (quilt) ;
* ajout de l'assistance pour la commande dh_dkms :
+ ajout de dkms à Build-Depends,
+ utilisation de dh $@ --with dkms à la place,
+ conséquence : gestion correcte de l'utilisation de DKMS
par les paquets de modules du noyau ;
* ajout de l'assistance pour les commandes
dh_autotools-dev_updateconfig et
dh_autotools-dev_restoreconfig :
+ ajout de autotools-dev à Build-Depends,
+ utilisation de dh $@ --with autotools-dev à la place,
+ conséquence : mise à jour et restauration de config.sub
et config.guess ;
* ajout de l'assistance pour les commandes dh_autoreconf et
dh_autoreconf_clean :
+ ajout de dh-autoreconf à Build-Depends,
+ utilisation de dh $@ --with autoreconf à la place,
+ conséquence : mise à jour des fichiers du système de
construction GNU et restauration de ceux-ci après la
construction ;
* ajout de l'assistance pour la commande dh_girepository :
+ ajout de gobject-introspection à Build-Depends,
+ utilisation de dh $@ --with gir à la place,
+ conséquence : calcul des dépendances pour les paquets
embarquant des données d'introspection GObject et
génération de la variable de substitution ${gir:Depends}
pour les dépendances du paquet ;
* ajout de l'assistance pour la fonctionnalité de complétion de
bash :
+ ajout de bash-completion à Build-Depends,
+ utilisation de dh $@ --with bash-completion à la place,
+ conséquence : installation des complétions de bash en
utilisant un fichier de configuration debian/paquet
.bash-completion.
De nombreuses commandes dh_* invoquées par la nouvelle commande
dh peuvent être personnalisées par les fichiers de configuration
correspondants dans le répertoire debian. Consultez Chapitre 5,
Autres fichiers dans le répertoire debian et la page de manuel de
chaque commande pour la personnalisation de telles
fonctionnalités.
Certaines commandes dh_*, invoquées à l'aide de la nouvelle
commande dh, doivent parfois être exécutées avec des arguments
supplémentaires, exécuter d'autres commandes avec elles ou être
ignorées. Pour cela, créez une cible override_dh_toto avec sa
règle dans le fichier rules définissant une cible override_dh_
toto pour remplacer la commande dh_toto. Son rôle est
fondamentalement de dire exécute-moi à la place. ^[51]
Les commandes dh_auto_* ont tendance à en faire plus que ce qui a
été présenté ici (très) simplement, pour prendre en compte toutes
les situations délicates. Évitez d'utiliser les cibles
override_dh_* pour remplacer dh_* par des commandes équivalentes
simplifiées (à part pour la cible override_dh_auto_clean) car
elles pourraient contourner des fonctionnalités intelligentes de
debhelper.
Ainsi, par exemple pour conserver les données de configuration
dans le répertoire /etc/gentoo au lieu du répertoire consacré /
etc du dernier paquet gentoo utilisant Autotools, il suffit de
remplacer l'option --sysconfig=/etc donnée par la commande
dh_auto_configure à la commande ./configure avec :
override_dh_auto_configure:
dh_auto_configure -- --sysconfig=/etc/gentoo
Les options données après -- sont ajoutées aux options par défaut
du programme exécuté automatiquement dans le but de les
remplacer. L'utilisation de la commande dh_auto_configure est ici
préférable à l'appel de la commande ./configure puisqu'elle
remplacera seulement l'option --sysconfig et conservera toutes
les autres options à propos de la commande ./configure.
Si le Makefile des sources de gentoo nécessite de préciser build
comme cible pour la construction ^[52], vous pouvez créer une
cible override_dh_auto_build pour cela.
override_dh_auto_build:
dh_auto_build -- build
Cela garantit l'exécution de $(MAKE) avec toutes les options par
défaut données à la commande dh_auto_build avec en plus le
paramètre build.
Si le Makefile des sources de gentoo oblige à préciser la cible
packageclean pour nettoyer le paquet Debian au lieu d'utiliser
les cibles distclean ou clean, vous pouvez créer une cible
override_dh_auto_clean pour l'activer.
override_dh_auto_clean:
$(MAKE) packageclean
Si le Makefile des sources pour gentoo contient une cible test
dont vous ne voulez pas pour exécuter le processus de
construction du paquet Debian, vous pouvez utiliser une cible
override_dh_auto_test vide pour l'omettre.
override_dh_auto_test:
Si gentoo possède un fichier journal de modification inhabituel
appelé FIXES, dh_installchangelogs ne l'installera pas par
défaut. La commande dh_installchangelogs a besoin de FIXES en
option pour l'installer. ^[53]
override_dh_installchangelogs:
dh_installchangelogs FIXES
Lors de l'utilisation de la nouvelle commande dh, la
compréhension des effets exacts des cibles explicites comme
celles énumérées en Section 4.4.1, « Cibles du fichier rules » (à
part get-orig-source) peut être rendue difficile. Veuillez
limiter les cibles explicites aux cibles override_dh_*, et à
celles complètement indépendantes, si possible.
---------------------------------------------------------------------
^[27] Dans ce chapitre, le préfixe debian/ est omis pour
simplifier l'écriture des fichiers du répertoire debian quand la
signification n'est pas ambiguë.
^[28] Consultez la Charte Debian, 2.4 « Sections » et la liste
des sections dans sid.
^[29] Consultez la Charte Debian, 2.5 « Priorités ».
^[30] Consultez la Charte Debian, 7.7 « Relations entre paquets
source et binaires — Build-Depends, Build-Depends-Indep,
Build-Conflicts, Build-Conflicts-Indep »
^[31] Cette situation quelque peu étrange est une fonctionnalité
bien expliquée dans la Charte Debian, note de bas de page 55. Ce
n'est pas lié à l'utilisation de la commande dh dans le fichier
debian/rules mais au fonctionnement de dpkg-buildpackage. La même
situation s'applique au système de construction automatique pour
Ubuntu.
^[32] Consultez la Charte Debian, 5.6.8 « Architecture » pour de
plus amples précisions.
^[33] Consultez la Charte Debian, 7 « Déclaration de relations
entre paquets ».
^[34] Ces descriptions sont en anglais. Les traductions de ces
descriptions sont fournies par Le projet de traduction de
descriptions de Debian — DDTP.
^[35] Consultez la référence du Développeur Debian,
6.2.5. « Emplacement du système de gestion de versions ».
^[36] Si vous utilisez la commande dch -r pour faire cette
dernière modification, n'oublier pas de sauver le fichier
changelog explicitement dans l'éditeur.
^[37] Vous pouvez apprendre les bases pour écrire un Makefile
dans la référence Debian, 12.2. « Make ». La documentation
complète est disponible en http://www.gnu.org/software/make/
manual/html_node/index.html et dans le paquet make-doc de la
partie non-free de l'archive.
^[38] La Charte Debian, 4.9 « Script de construction principal :
debian/rules » explique les détails.
^[39] Cette cible est utilisée par dpkg-buildpackage comme en
Section 6.1, « Reconstruction complète ».
^[40] Cette cible est utilisée par dpkg-buildpackage -B comme en
Section 6.2, « Serveurs d'empaquetage automatique
(« autobuilder ») ».
^[41] Cette cible est utilisée par dpkg-buildpackage -A.
^[42] Cela utilise les fonctionnalités du nouveau debhelper v7+.
Ses concepts fondateurs sont expliqués dans la présentation Pas
le debhelper de papy réalisé lors de Debconf9 par l'auteur de
debhelper. Sous Lenny, dh_make créait un fichier rules beaucoup
plus compliqué avec des règles explicites et de nombreux scripts
dh_* énumérés pour chacune, la plupart n'étant plus nécessaires
maintenant (et montrant l'âge du paquet). La nouvelle commande dh
plus simple libère le responsable de ce travail de routine
« manuel ». Vous gardez les pleins pouvoirs de personnalisation
du processus avec les cibles override_dh_*. Consultez
Section 4.4.3, « Personnalisation du fichier rules ». Il se base
uniquement sur le paquet debhelper et ne rend pas obscur le
processus de construction comme le paquet cdbs a tendance à le
faire.
^[43] You can verify the actual sequences of dh_* programs
invoked for a given target without really running them by
invoking dh target --no-act or debian/rules -- 'target --no-act'.
^[44] L'exemple suivant suppose que debian/compat a une valeur au
moins égale à 9 pour éviter d'invoquer une commande d'assistance
Python automatiquement.
^[45] Pour obtenir des renseignements complets sur le rôle exact
de tous ces scripts dh_* et sur leurs options, veuillez lire leur
page de manuel respective et la documentation de debhelper.
^[46] Ces commandes gèrent d'autres environnements, comme
setup.py, qui peuvent être énumérés en exécutant dh_auto_build
--list dans le répertoire d'un paquet source.
^[47] En fait, il recherche la première cible disponible dans le
Makefile parmi distclean, realclean et clean, et l'exécute.
^[48] En fait, il recherche dans le Makefile la première cible
disponible parmi test et check, et l'exécute.
^[49] Si un paquet installe le fichier /usr/share/perl5/Debian/
Debhelper/Sequence/nom_personnalise.pm, vous devriez déclencher
sa fonction de personnalisation avec dh $@ --with
nom-personnalise.
^[50] L'utilisation de la commande dh_python2 est préférable à
dh_pysupport ou dh_pycentral. N'utilisez pas la commande
dh_python.
^[51] Avec Lenny, pour modifier le comportement d'un script dh_*
il fallait trouver et adapter la ligne pertinente du fichier
rules.
^[52] dh_auto_build sans autre option exécutera la première cible
du Makefile.
^[53] Les fichiers debian/changelog et debian/NEWS sont toujours
installés automatiquement. Le journal de modification amont est
trouvé en convertissant les noms de fichiers en minuscule puis en
vérifiant l'existence de changelog, changes, changelog.txt et
changes.txt.
Chapitre 5. Autres fichiers dans le répertoire debian
The dh_make command had major updates since this old document was
written. So some parts of this document aren't applicable any
more.
La réécriture de ce tutoriel avec des contenus à jour et des
exemples pratiques supplémentaires est disponible sur Guide du
responsable Debian. Veuillez utiliser ce nouveau tutoriel comme
document principal.
The debmake command is used in place of the dh_make command in my
new Guide for Debian Maintainers.
Pour contrôler la plupart des actions de debhelper lors de la
construction du paquet, placez des fichiers de configuration
optionnels dans le répertoire debian. Ce chapitre présentera
globalement le rôle de ces fichiers et leur format. Veuillez
consulter la Charte Debian et la référence du développeur Debian
pour les principes d'empaquetage.
The dh_make command will create some template configuration files
under the debian directory. Take a look at all of them.
Dans ce chapitre, le préfixe debian/ est omis pour simplifier
l'écriture des fichiers du répertoire debian quand la
signification n'est pas ambiguë.
Certains modèles de fichiers de configuration de debhelper
risquent de ne pas être créés par la commande dh_make. Dans ce
cas, vous devez les créer avec un éditeur.
Pour activer certains d'entre eux, veuillez suivre les
instructions suivantes :
* renommez les fichiers de configuration pour utiliser le
véritable nom du paquet binaire à la place de paquet ;
* modifiez le contenu des fichiers modèles selon vos besoins ;
* enlevez les fichiers modèles dont vous n'avez pas besoin ;
* si nécessaire, modifiez le fichier control (consultez
Section 4.1, « control ») ;
* si nécessaire, modifiez le fichier rules (consultez
Section 4.4, « rules »).
Les fichiers de configuration de debhelper sans préfixe paquet
comme install sont relatifs au premier paquet binaire. Lorsqu'il
y a plusieurs paquets binaires, leur configuration respective
peut être précisée en ajoutant leur nom en préfixe du nom de
fichier de configuration : paquet-1.install, paquet-2
.install, etc.
5.1. README.Debian
Tous les détails ou différences entre le paquet original et votre
version Debian devraient être documentés ici.
dh_make en crée un par défaut, qui ressemble à ceci :
gentoo for Debian
-----------------
<possible notes regarding this package - if none, delete this file>
-- Josip Rodin <joy-mg@debian.org>, Wed, 11 Nov 1998 21:02:14 +0100
Si vous n'avez rien à documenter, effacez ce fichier, consultez
dh_installdocs(1).
5.2. compat
Le fichier compat définit le niveau de compatibilité de
debhelper. Actuellement, vous devriez le définir à debhelper v10
comme suit :
$ echo 10 > debian/compat
Vous pouvez utiliser le niveau de compatibilité v9 dans certaines
circonstances pour une compatibilité avec les anciennes versions.
Cependant, utiliser un niveau inférieur à v9 n’est pas recommandé
et devrait être évité pour les nouveaux paquets.
5.3. conffiles
Une des choses les plus irritantes à propos des logiciels est de
consacrer beaucoup de temps et d'efforts pour configurer un
programme, et de voir une seule mise à jour détruire tous ses
changements. Debian résout ce problème en marquant ces fichiers
de configuration comme des conffiles. ^[54] Lors de la mise à
jour d'un paquet, une question sera posée, permettant de garder
les anciens fichiers de configuration ou non.
dh_installdeb(1) considère automatiquement tous les fichiers du
répertoire /etc comme des conffiles, donc si tous les fichiers de
configuration de votre programme sont dans ce répertoire, il
n'est pas nécessaire de les indiquer dans ce fichier. Pour la
plupart des paquets, le seul endroit devant contenir des
conffiles est /etc, donc ce fichier ne devrait pas exister.
Si votre programme utilise des fichiers de configuration, mais
les réécrit aussi de son côté, il vaut mieux ne pas les marquer
comme conffiles, parce que dpkg va alors interroger les
utilisateurs pour vérifier les modifications tout le temps.
Si le programme que vous empaquetez force tous les utilisateurs à
modifier les fichiers de configuration du répertoire /etc, il y a
deux façons classiques de ne pas les marquer comme conffiles, et
garder dpkg silencieux :
* créer un lien symbolique dans le répertoire /etc vers un
fichier du répertoire /var créé par les scripts du
responsable ;
* créer un fichier généré par les scripts du responsable dans
le répertoire /etc.
Pour obtenir des renseignements sur les scripts du responsable,
consultez Section 5.18, « {post,pre}{inst,rm} ».
5.4. paquet.cron.*
Si le paquet a besoin d'exécuter des tâches régulièrement pour
fonctionner correctement, vous pouvez utiliser ces fichiers pour
les configurer. Vous pouvez programmer des tâches régulières
horaires, quotidiennes, mensuelles ou qui se produiront au moment
que vous préférez. Les noms de fichiers sont :
* paquet.cron.hourly — installé comme /etc/cron.hourly/paquet
et exécuté une fois par heure ;
* paquet.cron.daily — installé comme /etc/cron.daily/paquet et
exécuté une fois par jour ;
* paquet.cron.weekly — installé comme /etc/cron.weekly/paquet
et exécuté une fois par semaine ;
* paquet.cron.monthly — installé comme /etc/cron.monthly/paquet
et exécuté une fois par mois ;
* paquet.cron.d — installé comme /etc/cron.d/paquet et exécuté
à tout autre moment.
La plupart de ces fichiers sont des scripts shell, à l'exception
de paquet.cron.d dont le format est celui de crontab(5).
Aucun fichier cron.* n'est nécessaire pour configurer la rotation
des journaux ; pour cela, voyez dh_installlogrotate(1) et
logrotate(8).
5.5. dirs
Ce fichier indique les répertoires nécessaires mais qui ne sont
pas créés par la procédure d'installation normale (make install
DESTDIR=... invoquée par dh_auto_install). C'est souvent dû à un
problème avec le Makefile.
Les fichiers énumérés dans un fichier install n'ont pas besoin
que leurs répertoires soient créés avant, consultez Section 5.11,
« install ».
Il est préférable d'essayer d'exécuter l'installation, et
d'utiliser seulement ce recours si vous avez des problèmes. Il
n'y a pas de barre oblique (/) au début des noms de répertoire
dans la liste du fichier dirs.
5.6. paquet.doc-base
Si votre paquet est fourni avec une autre documentation que des
pages de manuel et d'information, vous devriez utiliser le
fichier doc-base pour l'enregistrer, de sorte que l'utilisateur
puisse la trouver avec par exemple dhelp(1), dwww(1) ou
doccentral(1).
Cela inclut normalement les fichiers HTML, PS et PDF, inclus dans
/usr/share/doc/nomdepaquet/.
Voici ce à quoi le fichier gentoo.doc-base de gentoo ressemble :
Document: gentoo
Title: Gentoo Manual
Author: Emil Brink
Abstract: This manual describes what Gentoo is, and how it can be used.
Section: File Management
Format: HTML
Index: /usr/share/doc/gentoo/html/index.html
Files: /usr/share/doc/gentoo/html/*.html
Pour obtenir plus de renseignements sur le format de ce fichier,
consultez install-docs(8) et la copie locale /usr/share/doc/
doc-base/doc-base.html/index.html du manuel Debian de doc-base.
Pour obtenir plus de renseignements sur l'installation de
documentation supplémentaire, consultez Section 3.3,
« Installation des fichiers à leur emplacement ».
5.7. docs
Ce fichier spécifie les noms des fichiers de documentation que
dh_installdocs(1) peut installer pour vous dans le répertoire
temporaire.
Par défaut, il inclut tous les fichiers, existant dans le
répertoire racine des sources, qui sont nommés BUGS, README*,
TODO, etc.
Pour gentoo, d'autres fichiers sont aussi inclus :
BUGS
CONFIG-CHANGES
CREDITS
NEWS
README
README.gtkrc
TODO
5.8. emacsen-*
Si votre paquet fournit des fichiers Emacs qui peuvent être
compilés en bytecode au moment de l'installation, vous pouvez
utiliser ces fichiers pour les configurer.
Ils sont installés dans le répertoire temporaire par
dh_installemacsen(1).
Si vous n'en avez pas besoin, effacez-les.
5.9. paquet.examples
La commande dh_installexamples(1) installe les fichiers et
répertoires énumérés ici comme des fichiers d'exemple.
5.10. paquet.init et paquet.default
Si votre paquet est un démon qui doit être exécuté au démarrage
du système, vous avez de toute évidence ignoré les
recommandations initiales, n'est-ce-pas ? :-)
Please read dh_installinit(1) dh_installsystemd(1) to provide
startup script.
The package.default file will be installed as /etc/default/
package. This file sets defaults that are sourced by the init
script. This package.default file is most often used to set some
default flags or timeouts. If your init script has certain
configurable features, you can set them in the package.default
file, instead of in the init script itself.
Si le programme amont fournit un fichier pour le script
d'initialisation, vous avez le choix de l'utiliser ou non. Si
vous n'utilisez pas leur script d'initialisation, créez-en un
nouveau en paquet.init. Cependant, si le script d'initialisation
amont semble fonctionnel et s'installe au bon endroit, il vous
faudra tout de même configurer le lien symbolique rc*. Pour cela,
il faut remplacer dh_installinit dans le fichier rules avec les
lignes suivantes :
override_dh_installinit:
dh_installinit --onlyscripts
Si vous n'en avez pas besoin, effacez ces fichiers.
5.11. install
Si des fichiers doivent être installés dans le paquet mais que
make install normal ne le fait pas, il faut ajouter les noms de
fichiers et leur destination dans ce fichier install. Ils sont
installés par dh_install(1).^[55] Vous devriez d'abord vérifier
s'il n'y a pas un outil plus approprié à utiliser. Par exemple,
les documents devraient être dans le fichier docs et non dans
celui-ci.
Ce fichier install possède une ligne par fichier installé, avec
le nom du fichier (par rapport au répertoire de construction
principal) suivi d'une espace puis du répertoire d'installation
(par rapport au répertoire d'install). Par exemple, si un binaire
src/truc n'est pas installé, le fichier install pourrait
ressembler à :
src/truc usr/bin
Cela signifie que lors de l'installation du paquet, il y aura une
commande exécutable /usr/bin/truc.
Ce fichier install peut renseigner seulement le nom du fichier
sans le répertoire d'installation quand le chemin relatif n'est
pas modifié. Ce format est normalement utilisé pour un gros
paquet qui découpe le résultat de la construction en plusieurs
paquets binaires à l'aide de paquet-1.install, paquet-2
.install, etc.
La commande dh_install finira par chercher les fichiers dans
debian/tmp, s'il ne les trouve pas dans le répertoire courant (ou
quelque soit l'endroit où il lui a été demandé de chercher avec
--sourcedir).
5.12. paquet.info
Si le paquet possède des pages d'information, vous devriez les
installer avec dh_installinfo(1) en les énumérant dans un fichier
paquet.info.
5.13. paquet.links
Pour créer des liens symboliques supplémentaires dans les
répertoires de construction du paquet en tant que responsable du
paquet, vous devriez les installer avec dh_link(1) en énumérant
leurs chemins complets de fichiers source et destination dans un
fichier paquet.links.
5.14. {paquet.,source/}lintian-overrides
Si lintian signale des erreurs dans son diagnostic alors que la
Charte accepte des exceptions à certaines règles, vous pouvez
utiliser paquet.lintian-overrides ou source/lintian-overrides
pour le rendre silencieux. Veuillez lire le manuel utilisateur de
Lintian (https://lintian.debian.org/manual/index.html) et vous
abstenir d'en abuser.
paquet.lintian-overrides concerne le paquet binaire appelé paquet
, il est installé en usr/share/lintian/overrides/paquet par la
commande dh_lintian.
source/lintian-overrides concerne le paquet source. Il n'est pas
installé.
5.15. manpage.*
Le programme devrait être livré avec une page de manuel. Sinon,
vous devriez en créer au moins une. La commande dh_make crée
quelques modèles de fichiers pour pages de manuel. Ils doivent
être copiés et modifiés pour chaque commande à laquelle il manque
une page de manuel. Veuillez vous assurer d'avoir effacé les
modèles non utilisés.
5.15.1. manpage.1.ex
Les pages de manuel sont normalement écrites en nroff(1).
L'exemple manpage.1.ex est aussi écrit en nroff. Lisez la page de
manuel man(7) pour une brève description sur la façon d'éditer ce
genre de fichiers.
Le nom de fichier de la page de manuel devrait donner le nom du
programme qu'elle documente, donc manpage doit être renommé en
gentoo. Le nom de fichier inclut aussi .1 comme premier suffixe,
qui signifie que c'est une page de manuel pour une commande
utilisateur. Assurez-vous de vérifier que cette section est
effectivement la bonne. Voici une courte liste des sections de
pages de manuel :
+---------------------------------------------------------------+
|Section| Description | Remarques |
|-------+----------------+--------------------------------------|
|1 |Commandes |Commandes ou scripts exécutables |
| |utilisateur | |
|-------+----------------+--------------------------------------|
|2 |Appels système |Fonctions fournies par le noyau |
|-------+----------------+--------------------------------------|
|3 |Appels de |Fonctions des bibliothèques système |
| |bibliothèque | |
|-------+----------------+--------------------------------------|
|4 |Fichiers |Situés généralement dans /dev |
| |spéciaux | |
|-------+----------------+--------------------------------------|
|5 |Formats de |Par exemple le format de /etc/passwd |
| |fichier | |
|-------+----------------+--------------------------------------|
|6 |Jeux |Jeux ou autres programmes frivoles |
|-------+----------------+--------------------------------------|
|7 |Macropaquets |Comme les macros de man |
|-------+----------------+--------------------------------------|
|8 |Administration |Programmes normalement exécutés par le|
| |système |superutilisateur |
|-------+----------------+--------------------------------------|
|9 |Sous-programmes |Appels non standard et routines |
| |du noyau |internes |
+---------------------------------------------------------------+
Ainsi, la page de manuel de gentoo devrait être appelée gentoo.1.
S'il n'y avait pas de page de manuel gentoo.1 dans les sources
originales, il aurait fallu renommer le modèle manpage.1.ex en
gentoo.1 puis le modifier à partir des informations de l'exemple
et de la documentation amont.
La commande help2man peut aussi être utilisée pour créer une page
de manuel à partir de la sortie de --help et --version pour
chaque programme. ^[56]
5.15.2. manpage.sgml.ex
D'un autre côté, si vous préférez écrire du SGML plutôt que du
nroff, vous pouvez utiliser le modèle manpage.sgml.ex. Si vous le
faites, vous devez :
* renommer le fichier en quelque chose comme gentoo.sgml ;
* installer le paquet docbook-to-man ;
* ajouter docbook-to-man à la ligne Build-Depends dans le
fichier control ;
* ajouter une cible override_dh_auto_build au fichier rules :
override_dh_auto_build:
docbook-to-man debian/gentoo.sgml > debian/gentoo.1
dh_auto_build
5.15.3. manpage.xml.ex
Si vous préférez XML à SGML, vous pouvez utiliser le modèle
manpage.xml.ex. Si vous le faites, vous devez :
* renommer le fichier en quelque chose comme gentoo.xml ;
* installer le paquet docbook-xsl et un processeur XSLT comme
xsltproc (recommandé) ;
* ajouter docbook-xsl, docbook-xml et xsltproc à la ligne
Build-Depends dans le fichier control ;
* ajouter une cible override_dh_auto_build au fichier rules :
override_dh_auto_build:
xsltproc --nonet \
--param make.year.ranges 1 \
--param make.single.year.ranges 1 \
--param man.charmap.use.subset 0 \
-o debian/ \
http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl\
debian/gentoo.1.xml
dh_auto_build
5.16. paquet.manpages
Si le paquet possède des pages de manuel, vous devriez les
installer avec dh_installman(1) en les énumérant dans un fichier
paquet.manpages.
Pour installer docs/gentoo.1 en tant que page de manuel du paquet
gentoo, créez le fichier gentoo.manpages contenant :
docs/gentoo.1
5.17. NEWS
La commande dh_installchangelogs(1) l'installe.
5.18. {post,pre}{inst,rm}
Les fichiers postinst, preinst, postrm, et prerm ^[57] sont
nommés scripts du responsable. Ces scripts sont placés dans la
zone de contrôle du paquet et sont exécutés par dpkg lorsque le
paquet est installé, mis à jour ou supprimé.
En tant que responsable débutant, vous devriez éviter de modifier
manuellement les scripts du responsable parce qu'ils ont tendance
à être complexes. Pour obtenir plus de renseignements, consultez
dans la Charte Debian, chapitre 6 « scripts du responsable et
procédure d'installation » et examinez les fichiers d'exemple
fournis par dh_make.
Si vous préférez n'en faire qu'à votre tête en créant vos propres
scripts du responsable pour un paquet, vous devriez les essayer
non seulement lors de l'installation et la mise à jour, mais
aussi pour la désinstallation et la purge.
Les mises à niveau vers de nouvelles versions devraient être
silencieuses et non intrusives (les utilisateurs existants ne
devraient pas remarquer la mise à niveau à part en constatant la
résolution de vieux bogues et peut-être l'arrivée de nouvelles
fonctionnalités).
Lorsque la mise à niveau est forcément intrusive (par exemple des
fichiers de configuration dispersés dans plusieurs répertoires
personnels avec des structures complètement différentes), vous
pouvez envisager en dernier recours de basculer le paquet vers un
état de repli sûr (par exemple en désactivant un service) et en
fournissant la documentation adéquate conformément à la Charte
Debian (README.Debian et NEWS.Debian). N'embêtez pas
l'utilisateur avec des notes debconf déclenchées par les scripts
du responsable lors des mises à niveau.
Le paquet ucf fournit un dispositif à la conffile pour conserver
les modifications des utilisateurs pour les fichiers qui n'ont
pas été marqués comme conffiles comme ceux gérés par les scripts
du responsable. Cela permet de réduire les problèmes associés à
ces fichiers.
Ces scripts du responsable font partie des améliorations de
Debian qui expliquent pourquoi les gens choisissent Debian.
Prenez garde de ne pas les transformer en source d'agacement.
5.19. paquet.symbols
L'empaquetage de bibliothèque n'est pas facile pour un mainteneur
débutant, et devrait être évité. Cela dit, si le paquet fournit
des bibliothèques, des fichiers debian/paquet.symbols devraient
exister. Consultez Section A.2, « Gestion de debian/paquet
.symbols ».
5.20. TODO
La commande dh_installdocs(1) l'installe.
5.21. watch
Le format du fichier watch est documenté dans la page de manuel
uscan(1). Le fichier watch configure le programme uscan (dans le
paquet devscripts) pour surveiller le site sur lequel vous avez
obtenu les sources. C'est également utilisé par le service Debian
Package Tracker.
Voici ce qu'il contient :
# watch control file for uscan
version=3
http://sf.net/gentoo/gentoo-(.+)\.tar\.gz debian uupdate
Normalement, avec un fichier watch, la page servie à l'URL http:/
/sf.net/gentoo est téléchargée pour chercher des liens sous la
forme <a href=...>. Le nom de base (juste après la dernière /) de
chaque URL liée est comparé au motif de l'expression rationnelle
Perl gentoo-(.+)\.tar\.gz (consultez perlre(1)). Parmi les
fichiers correspondants, celui avec le plus grand numéro de
version est téléchargé puis le programme uupdate est exécuté pour
créer une arborescence source mise à jour.
Bien que ce soit vrai pour les autres sites, le service de
téléchargement de SourceForge en http://sf.net est une exception.
Quand le fichier watch comporte une URL correspondant au motif
d'expression rationnelle ^http://sf\.net/, le programme uscan le
remplace par http://qa.debian.org/watch/sf.php/ et applique
ensuite cette règle. Le service de redirection en http://
qa.debian.org/ est conçu pour offrir un service stable vers le
fichier voulu pour les motifs watch de la forme http://sf.net/
projet/nom-d-archive-(.+)\.tar\.gz. Le but est de résoudre le
problème lié au fréquent changement d'URL SourceForge.
Si la source propose une signature cryptographique pour
l’archive, il est recommandé de vérifier son authenticité en
utilisant l’option pgpsigurlmangle comme expliqué dans uscan(1).
5.22. source/format
Dans le fichier debian/source/format, il devrait y avoir une
seule ligne indiquant le format voulu du paquet source (consulter
en dpkg-source(1) pour une liste exhaustive). Après Squeeze, il
devrait contenir selon les cas :
* 3.0 (native) pour les paquets Debian natifs ;
* 3.0 (quilt) pour tout le reste.
Le récent format source 3.0 (quilt) enregistre les modifications
dans un ensemble de correctifs quilt dans debian/patches. Ces
changements sont alors appliqués automatiquement lors de
l'extraction du paquet source. ^[58] Les modifications Debian
sont simplement conservées dans une archive debian.tar.gz
contenant tous les fichiers du répertoire debian. Ce nouveau
format permet d'inclure des fichiers binaires comme des icônes
PNG sans bidouillage. ^[59]
Quand dpkg-source extrait un paquet source au format 3.0 (quilt),
il applique automatiquement tous les correctifs énumérés dans
debian/patches/series. Vous pouvez éviter que les correctifs
soient appliqués à la fin de l'extraction avec l'option
--skip-patches.
5.23. source/local-options
Lors de la maintenance de paquet Debian avec un système de
gestion de version, il faut généralement créer une branche (par
exemple, upstream) pour suivre les sources amont, et une autre
branche (typiquement master avec Git) pour suivre le paquet
Debian. Pour cette dernière, il est préférable de garder les
sources amont non modifiés aux côtés des fichiers debian/* du
paquet Debian pour faciliter la fusion avec les nouveaux sources
d’amont.
Après la construction d'un paquet, les sources sont normalement
laissés modifiés (« patched »). dquilt pop -a doit être exécuté
avant d'envoyer vers la branche master. Créer un fichier
optionnel debian/source/local-options contenant unapply-patches
permet d'automatiser cela. Ce fichier n'est pas inclus dans le
paquet source créé et modifie seulement le comportement de
construction local. Ce fichier peut aussi contenir
abort-on-upstream-changes (consultez dpkg-source(1)).
unapply-patches
abort-on-upstream-changes
5.24. source/options
Les fichiers créés automatiquement dans l'arborescence source
peuvent être assez agaçants pour l'empaquetage puisqu'ils sont à
l'origine de grands fichiers de correctif sans signification. Des
modules personnalisés comme dh_autoreconf permettent d'atténuer
ce problème comme décrit en Section 4.4.3, « Personnalisation du
fichier rules ».
Vous pouvez fournir une expression rationnelle Perl en argument
de l'option --extend-diff-ignore de dpkg-source(1) pour ignorer
les modifications faites aux fichiers créés automatiquement lors
de la création du paquet source.
Comme solution générique pour aborder ce problème de fichiers
créés automatiquement, vous pouvez enregistrer ces arguments
d'option de dpkg-source dans le fichier source/options du paquet
source. L'exemple suivant permet de sauter la création de
fichiers de correctif pour config.sub, config.guess et Makefile :
extend-diff-ignore = "(^|/)(config\.sub|config\.guess|Makefile)$"
5.25. patches/*
L'ancien format source 1.0 créait un unique et gros fichier
diff.gz contenant les fichiers de maintenance du paquet dans
debian et les correctifs aux sources. Un tel paquet est un peu
délicat à inspecter et à comprendre pour chaque modification de
l'arbre source par la suite. Ce n'est pas conseillé.
Le nouveau format source 3.0 (quilt) conserve les correctifs dans
les fichiers debian/patches/* en utilisant la commande quilt. Ces
correctifs et les autres données de paquet qui sont tous contenus
dans le répertoire debian sont empaquetés dans le fichier
debian.tar.gz. Puisque la commande dpkg-source peut gérer les
correctifs au format quilt dans le source 3.0 (quilt) sans le
paquet quilt, il n'est pas nécessaire d'ajouter quilt à
Build-Depends. ^[60]
La commande quilt est expliquée en quilt(1). Elle enregistre les
modifications des sources comme une pile de fichiers correctifs
-p1 dans le répertoire debian/patches et l'arborescence source
n'est pas modifiée en dehors du répertoire debian. L'ordre
d'application de ces correctifs est enregistré dans le fichier
debian/patches/series. Vous pouvez appliquer (« push »), enlever
(« pop »), et rafraîchir (« refresh ») les correctifs facilement.
^[61]
En Chapitre 3, Modification du code source, trois correctifs ont
été créés dans debian/patches.
Puisque les correctifs Debian sont localisés en debian/patches,
veuillez vous assurer d'avoir configuré correctement la commande
dquilt conformément à la description en Section 3.1,
« Configuration de quilt ».
Quand quelqu'un (éventuellement vous-même) fournit un correctif
toto.patch par la suite, la modification d'un paquet source 3.0
(quilt) est assez simple :
$ dpkg-source -x gentoo_0.9.12.dsc
$ cd gentoo-0.9.12
$ dquilt import ../toto.patch
$ dquilt push
$ dquilt refresh
$ dquilt header -e
... description du correctif
Les correctifs conservés au nouveau format source 3.0 (quilt)
doivent être sans approximation (« fuzz »). Vous pouvez vous en
assurer avec dquilt pop -a; while dquilt push; do dquilt refresh;
done.
---------------------------------------------------------------------
^[54] Consultez dpkg(1) et la Charte Debian, D.2.5 « Conffiles ».
^[55] Cela remplace la commande obsolète dh_movefiles(1)
configurée par le fichier files.
^[56] Remarquez que la page de manuel initiale créée par help2man
prétendra que des renseignements supplémentaires sont disponibles
dans le système d'information. Si la commande n'a pas non plus de
page info, vous devriez modifier manuellement la page créée par
la commande help2man.
^[57] Malgré l'utilisation de raccourcis bash pour présenter les
noms des fichiers {pre,post}{inst,rm}, vous devriez utiliser une
syntaxe pure POSIX pour les scripts du responsable pour être
compatibles avec dash comme interpréteur de commande du système.
^[58] Consulter DebSrc3.0 pour un résumé de la conversion des
sources aux formats source 3.0 (quilt) et 3.0 (native).
^[59] En fait, ce nouveau format permet de gérer des archives
amont multiples et plusieurs méthodes de compression. Ces
considérations sortent du cadre de ce document.
^[60] Plusieurs méthodes de maintenance des ensembles de
correctifs ont été proposées et sont utilisées dans les paquets
Debian. Le système quilt est le système de maintenance conseillé.
Parmi d'autres, dpatch, dbs et cdbs existent. La plupart d'entre
eux conservent de tels correctifs dans des fichiers debian/
patches/*.
^[61] Si vous demandez à un parrain d'envoyer le paquet, cette
sorte de séparation claire et la documentation de vos
modifications sont très importantes pour accélérer l'examen du
paquet.
Chapitre 6. Construction du paquet
La réécriture de ce tutoriel avec des contenus à jour et des
exemples pratiques supplémentaires est disponible sur Guide du
responsable Debian. Veuillez utiliser ce nouveau tutoriel comme
document principal.
Tout devrait maintenant être prêt pour construire le paquet.
6.1. Reconstruction complète
Pour réaliser correctement la reconstruction complète d'un
paquet, doivent être installés :
* le paquet build-essential ;
* les paquets énumérés dans le champ Build-Depends (consultez
Section 4.1, « control ») ;
* les paquets énumérés dans le champ Build-Depends-indep
(consultez Section 4.1, « control »).
Ensuite, exécutez la commande suivante dans le répertoire des
sources :
$ dpkg-buildpackage -us -uc
Cela fera tout le nécessaire pour créer entièrement les paquets
binaires et source à votre place :
* nettoyage de l'arbre des sources (debian/rules clean) ;
* construction du paquet source (dpkg-source -b) ;
* construction du programme (debian/rules build) ;
* construction des paquets binaires (fakeroot debian/rules
binary) ;
* création du fichier .dsc ;
* création du fichier .changes, en utilisant dpkg-genchanges.
Si le résultat de la construction est satisfaisant, signez les
fichiers .dsc et .changes avec votre clef privée GPG avec la
commande debsign. Vous devez entrer votre phrase secrète deux
fois. ^[62]
Pour un paquet Debian non natif, par exemple gentoo, vous verrez
les fichiers suivants dans le répertoire parent (~/gentoo) après
la construction des paquets :
* gentoo_0.9.12.orig.tar.gz
C'est le code source amont d'origine, simplement renommé pour
être conforme aux normes Debian. Il a été créé au début avec
la commande dh_make -f ../gentoo-0.9.12.tar.gz.
* gentoo_0.9.12-1.dsc
c'est un résumé du contenu du code source. Il est créé à
partir du fichier control, et est utilisé pour décompresser
les sources avec dpkg-source(1).
* gentoo_0.9.12-1.debian.tar.gz
Cette archive compressée contient le répertoire debian. Tous
les ajouts et modifications au code source d'origine sont
conservés en tant que correctif quilt dans debian/patches.
Si quelqu'un d'autre veut recréer le paquet depuis le début,
il peut facilement le faire en utilisant ces trois fichiers.
La procédure d'extraction est facile : copier simplement ces
trois fichiers quelque part et exécuter dpkg-source -x
gentoo_0.9.12-1.dsc.^[63]
* gentoo_0.9.12-1_i386.deb
c'est le paquet binaire terminé. Vous pouvez utiliser dpkg
pour l'installer ou le retirer comme n'importe quel autre
paquet.
* gentoo_0.9.12-1_i386.changes
Ce fichier décrit toutes les modifications effectuées dans la
révision actuelle du paquet, et est utilisé par les
programmes de maintenance des archives FTP Debian pour y
installer les paquets binaires et sources. Il est
partiellement créé à partir des fichiers changelog et .dsc.
Au fur et à mesure que vous travaillez sur le paquet, son
comportement va évoluer et de nouvelles fonctionnalités
seront ajoutées. Les gens qui téléchargent votre paquet
peuvent lire ce fichier et voir rapidement ce qui a changé.
Les programmes de maintenance des archives Debian vont aussi
poster le contenu de ce fichier sur la liste de diffusion
debian-devel-changes@lists.debian.org.
Les fichiers gentoo_0.9.12-1.dsc et gentoo_0.9.12-1_i386.changes
doivent être signés en utilisant la commande debsign avec votre
clef privée GPG du répertoire ~/.gnupg/, avant de les téléverser
dans l’archive FTP de Debian. La signature GPG fournit la preuve
que ce sont vraiment vos fichiers par l’utilisation de votre clef
publique GPG.
La commande debsign peut être utilisée pour signer avec votre
identifiant de clef secrète GPG (utile pour les paquets
parrainés) dans le fichier ~/.devscripts comme suit :
DEBSIGN_KEYID=Votre_ID_de_clef_GPG
Les longues chaînes de chiffres dans les fichiers .dsc et
.changes sont les sommes SHA1 et SHA256 des fichiers indiqués.
Les personnes téléchargeant vos fichiers peuvent les vérifier
avec sha1sum(1) ou sha256sum(1), et si les fichiers ne
correspondent pas, elles sauront que le fichier a été corrompu ou
falsifié.
6.2. Serveurs d'empaquetage automatique (« autobuilder »)
Debian gère de nombreux portages avec le réseau de serveurs
d'empaquetage automatique faisant fonctionner des démons buildd
sur de nombreux ordinateurs d'architectures différentes. Même si
vous n'avez pas besoin de le faire vous-même, vous devriez être
au courant de ce qui va arriver à vos paquets. La suite présente
brièvement comment les paquets sont reconstruits sur plusieurs
architectures. ^[64]
Les paquets Architecture: any sont reconstruits par les serveurs
d'empaquetage automatique. Seront installés :
* le paquet build-essential ;
* les paquets énumérés dans le champ Build-Depends, (consultez
Section 4.1, « control »).
Ensuite, la commande suivante est exécutée dans le répertoire des
sources :
$ dpkg-buildpackage -B
Cela fera tout le nécessaire pour créer entièrement les paquets
binaires dépendant de l'architecture sur l'architecture
concernée :
* nettoyage de l'arbre des sources (debian/rules clean) ;
* construction du programme (debian/rules build) ;
* construction des paquets binaires dépendants de
l'architecture (fakeroot debian/rules binary-arch) ;
* signature du fichier source .dsc, en utilisant gpg ;
* création et signature du fichier de téléchargement .changes,
en utilisant dpkg-genchanges et gpg.
C'est pourquoi votre paquet est disponible sur plusieurs
architectures.
Bien qu'il soit nécessaire d'installer les paquets énumérés dans
le champ Build-Depends-Indep pour l'empaquetage normal (consultez
Section 6.1, « Reconstruction complète »), il n'est pas
nécessaire de les installer sur le serveur d'empaquetage
automatique puisqu'il ne construit que les paquets binaires
dépendants de l'architecture. ^[65] Cette distinction entre
l'empaquetage normal et celui des serveurs d'empaquetage
automatique permet de déterminer si les paquets doivent être
énumérés dans le champ Build-Depends ou Build-Depends-Indep du
fichier debian/control (consultez Section 4.1, « control »).
6.3. Commande debuild
Vous pouvez automatiser le processus de construction en utilisant
la commande dpkg-buildpackage et empaqueter ensuite avec la
commande debuild, consultez debuild(1).
La commande debuild exécute la commande lintian pour une analyse
statique après la construction du paquet Debian. La commande
lintian peut être personnalisée dans ~/.devscripts avec ce qui
suit :
DEBUILD_DPKG_BUILDPACKAGE_OPTS="-us -uc -I -i"
DEBUILD_LINTIAN_OPTS="-i -I --show-overrides"
Le nettoyage des sources et la reconstruction du paquet avec un
compte utilisateur est aussi simple que :
$ debuild
Le nettoyage de l'arborescence des sources est aussi simple que :
$ debuild -- clean
6.4. Paquet pbuilder
Pour un environnement de construction propre (chroot) permettant
de vérifier les dépendances de construction, pbuilder est très
utile. ^[66] Cela garantit une construction propre des sources en
construction automatique sous sid pour différentes architectures
et évite une erreur sérieuse FTBFS (« Fails To Build From
Source » pour les échecs de construction à partir du paquet
source), qui est toujours en catégorie RC (« Release Critical »,
bloquant la publication). ^[67]
Le paquet pbuilder est personnalisable de la manière suivante :
* configuration du répertoire /var/cache/pbuilder/result
accessible en écriture pour l'utilisateur ;
* création d'un répertoire, par exemple /var/cache/pbuilder/
hooks, accessible en écriture pour l'utilisateur pour y
placer ses scripts hook ;
* configuration de ~/.pbuilderrc ou /etc/pbuilderrc pour
intégrer ce qui suit :
AUTO_DEBSIGN=${AUTO_DEBSIGN:-no}
HOOKDIR=/var/cache/pbuilder/hooks
D'abord, le système chroot local de pbuilder doit être
initialisé :
$ sudo pbuilder create
Si vous possédez déjà le paquet source terminé, exécutez les
commandes suivantes dans le répertoire contenant les fichiers
toto.orig.tar.gz, toto.debian.tar.gz, et toto.dsc pour mettre à
jour le système chroot de pbuilder et y construire les paquets
binaires :
$ sudo pbuilder --update
$ sudo pbuilder --build toto_version.dsc
Les paquets nouvellement créés sans signatures GPG sont
accessibles en /var/cache/pbuilder/result/ et n'appartiennent pas
au superutilisateur.
Les signatures GPG des fichiers .dsc et .changes peuvent être
créées avec :
$ cd /var/cache/pbuilder/result/
$ debsign toto_version_arch.changes
Si vous possédez une arborescence des sources à jour, mais n'avez
pas créé le paquet source correspondant, exécutez plutôt les
commandes suivantes dans le répertoire des sources ayant un
répertoire debian :
$ sudo pbuilder --update
$ pdebuild
Vous pouvez vous connecter à l'environnement chroot avec la
commande pbuilder --login --save-after-login et le configurer à
votre convenance. Cet environnement peut être sauvegardé en
quittant l'invite de commande avec ^D (Contrôle-D).
La dernière version de la commande lintian peut être exécutée
dans l'environnement chroot en utilisant le script hook /var/
cache/pbuilder/hooks/B90lintian configuré comme suit : ^[68]
#!/bin/sh
set -e
install_packages() {
apt-get -y --allow-downgrades install "$@"
}
install_packages lintian
echo "+++ lintian output +++"
su -c "lintian -i -I --show-overrides /tmp/buildd/*.changes" - pbuilder
# utilisez ceci si vous ne voulez pas que lintian arrête la construction
#su -c "lintian -i -I --show-overrides /tmp/buildd/*.changes; :" - pbuilder
echo "+++ end of lintian output +++"
Un environnement sid à jour est nécessaire pour construire
correctement les paquets destinés à sid. En pratique, sid peut
parfois être victime de problèmes qui peuvent rendre non
souhaitable la migration de votre système complet. Le paquet
pbuilder peut vous aider à faire face à ce genre de situation.
Vous pouvez avoir besoin de mettre à jour vos paquets stable
après sa publication à destination de stable-proposed-updates,
stable/updates, etc. ^[69] Dans ces cas-là, le fait d'utiliser
sid est une mauvaise excuse pour ne pas les mettre à jour au plus
tôt. Le paquet pbuilder vous permet d'accéder à la plupart des
distributions dérivées de Debian pour la même architecture.
Consultez http://www.netfort.gr.jp/~dancer/software/
pbuilder.html, pdebuild(1), pbuilderrc(5), et pbuilder(8).
6.5. Commandes git-buildpackage et similaires
Si les développeurs amont utilisent un système de gestion de
versions (VCS) ^[70] pour maintenir leur code source, vous
devriez envisager aussi de l'utiliser. Cela rend la fusion et la
sélection (« cherry-picking ») des correctifs amont plus faciles.
De nombreux paquets de scripts d'enrobage sont disponibles pour
la construction de paquets Debian pour chaque système de gestion
de versions :
* git-buildpackage : assistants pour les paquets Debian gérés
dans des dépôts Git ;
* svn-buildpackage : assistants pour la maintenance de paquets
Debian avec Subversion ;
* cvs-buildpackage : scripts pour paquets Debian pour les
arbres de sources CVS.
L'utilisation de git-buildpackage devient assez populaire parmi
les développeurs Debian pour gérer les paquets Debian avec le
serveur Git sur alioth.debian.org. ^[71] Ce paquet fournit
plusieurs commandes pour automatiser les activités
d'empaquetage :
* gbp-import-dsc(1): import a previous Debian package to a Git
repository.
* gbp-import-orig(1): import a new upstream tar to a Git
repository.
* gbp-dch(1): generate the Debian changelog from Git commit
messages.
* git-buildpackage(1) : construire des paquets Debian à partir
d'un dépôt Git ;
* git-pbuilder() : construire des paquets Debian à partir d'un
dépôt Git en utilisant pbuilder ou cowbuilder.
Ces commandes utilisent trois branches pour suivre les activités
d'empaquetage :
* main pour l'arborescence source de paquet Debian ;
* upstream pour l'arborescence source amont ;
* pristine-tar pour l'archive amont générée par l'option
--pristine-tar.^[72]
git-buildpackage peut être configuré dans ~/.gbp.conf. Consultez
gbp.conf(5). ^[73]
6.6. Reconstruction rapide
Avec un paquet imposant, vous ne voudrez sans doute pas
reconstruire depuis le début chaque fois que vous faites une
petite modification à debian/rules. Pour tester, vous pouvez
faire un fichier .deb sans reconstruire les sources amont comme
ceci ^[74] :
$ fakeroot debian/rules binary
Ou faites simplement comme suit pour voir s'il y a construction
ou non :
$ fakeroot debian/rules build
Une fois terminés vos ajustements, souvenez-vous de reconstruire
en suivant la procédure correcte ci-dessus. Vous pouvez être
incapable d'envoyer proprement si vous essayez d'envoyer des
fichiers .deb construits de cette façon.
6.7. Hiérarchie des commandes
Voici un résumé sommaire de la façon dont beaucoup de commandes
s’assemblent de manière hiérarchique. Il y a plusieurs manières
de faire la même chose :
* debian/rules = script du mainteneur pour la construction du
paquet ;
* dpkg-buildpackage = partie principale de l’outil de
construction de paquet ;
* debuild = dpkg-buildpackage + lintian (construction avec des
variables d’environnement vérifiées) ;
* pbuilder = partie principale de l’outil pour l’environnement
chroot de Debian ;
* pdebuild = pbuilder + dpkg-buildpackage (construction dans le
chroot) ;
* cowbuilder = accélération de l’exécution de pbuilder ;
* git-pbuilder = syntaxe d’utilisation aisée de ligne de
commande pour pdebuild (utilisée par gbp buildpackage) ;
* gbp = gestion des sources Debian dans le dépôt git ;
* gbp buildpackage = pbuilder + dpkg-buildpackage + gbp.
Bien que les commandes de haut niveau telles que gbp buildpackage
et pbuilder garantissent un environnement de construction de
paquet parfait, il est essentiel de comprendre comment les
commandes de bas niveau, telles que debian/rules et
dpkg-buildpackage, sont exécutées en dessous.
---------------------------------------------------------------------
^[62] Cette clef GPG doit être signée par un développeur Debian
pour être connectée au réseau de confiance et doit être
enregistrée dans le trousseau Debian. Cela permet à vos paquets
d'être acceptés dans l'archive Debian. Consultez la page de
création d'une nouvelle clef GPG et le wiki Debian à propos de la
signature de clef.
^[63] Il est possible de ne pas appliquer les correctifs quilt du
format source 3.0 (quilt) à la fin de l'extraction avec l'option
--skip-patches. Sinon, il est aussi possible d'exécuter dquilt
pop -a après l'extraction normale.
^[64] Le véritable réseau de serveurs d'empaquetage automatique a
un fonctionnement autrement plus compliqué que celui présenté
ici. De tels détails sortent du cadre de ce document.
^[65] Contrairement à celui du paquet pbuilder, l'environnement
chroot du paquet sbuild utilisé par les serveurs d'empaquetage
automatique n'est pas forcément minimal et plusieurs paquets
peuvent rester installés.
^[66] Comme le paquet pbuilder est en constante évolution, vous
devriez vérifier les possibilités réelles de la configuration en
consultant la dernière documentation officielle.
^[67] Consultez http://buildd.debian.org/ pour obtenir plus de
renseignements sur le service de construction automatique de
paquets Debian.
^[68] Cela suppose que HOOKDIR=/var/cache/pbuilder/hooks est déjà
configuré. De nombreux exemples de scripts hook sont disponibles
dans le répertoire /usr/share/doc/pbuilder/examples.
^[69] Il existe des restrictions pour de telles mises à jour de
paquet stable.
^[70] Consultez Systèmes de contrôle de versions pour obtenir
plus de renseignements.
^[71] Le wiki Debian sur Alioth documente la façon d'utiliser le
service alioth.debian.org.
^[72] L'option --pristine-tar invoque la commande pristine-tar
qui peut générer une copie exacte de l'archive amont d'origine en
n'utilisant qu'un petit fichier binaire de delta et le contenu de
l'archive amont, qui est normalement gardé dans une branche
upstream du système de gestion de versions.
^[73] Voici quelques ressources disponibles sur la toile pour les
utilisateurs avancés :
* Construction de paquets Debian avec git-buildpackage (/usr/
share/doc/git-buildpackage/manual-html/gbp.html) ;
* Paquets Debian avec Git ;
* Utilisation de Git pour l'empaquetage Debian ;
* git-dpm : paquets Debian dans le gestionnaire Git ;
^[74] Les variables d'environnement qui devraient normalement
être configurées correctement à cette étape ne sont pas
configurées par cette méthode. Ne créez jamais de vrais paquets
pour l'envoi avec cette méthode rapide.
Chapitre 7. Contrôle des erreurs du paquet
La réécriture de ce tutoriel avec des contenus à jour et des
exemples pratiques supplémentaires est disponible sur Guide du
responsable Debian. Veuillez utiliser ce nouveau tutoriel comme
document principal.
Quelques techniques sont à connaître pour rechercher des erreurs
sur le paquet avant de l'envoyer sur les archives publiques.
Il est aussi conseillé d'effectuer des essais sur une machine
différente de la vôtre. Vous devez observer de près chaque alerte
ou erreur pour tous les tests décrits ici.
7.1. Modifications suspectes
Si vous trouvez un nouveau fichier de correctif autocréé comme
debian-changes-* dans le répertoire debian/patches après la
construction de votre paquet Debian non natif au format 3.0
(quilt), il y a des chances que vous ayez accidentellement
modifié quelques fichiers ou que le script de construction ait
modifié les sources amont. Si c'est de votre faute, corrigez
votre erreur. Si c'est provoqué par le script de construction,
corrigez l'erreur à la racine avec dh-autoreconf comme en
Section 4.4.3, « Personnalisation du fichier rules » ou
contournez-la avec source/options comme en Section 5.24, « source
/options ».
7.2. Vérification de l'installation d'un paquet
Vous devez essayer votre paquet pour vérifier qu'il s'installe
sans problème. La commande debi(1) vous permet d'essayer
l'installation de tout paquet binaire créé.
$ sudo debi gentoo_0.9.12-1_i386.changes
Pour éviter les problèmes d'installation sur différents systèmes,
vous devez vérifier qu'il n'y a pas de nom de fichier en conflit
avec ceux existants dans d'autres paquets à l'aide du fichier
Contents-i386 téléchargé depuis l'archive Debian. La commande
apt-file peut être pratique pour cela. S'il existe des
collisions, veuillez prendre les mesures nécessaires pour éviter
ces vrais problèmes : en renommant le fichier, en déplaçant le
fichier commun dans un paquet différent dont plusieurs paquets
peuvent dépendre, en utilisant le mécanisme d'alternatives
(consultez update-alternatives(1)) en coordination avec les
responsables des autres paquets concernés, ou encore en déclarant
une relation de Conflicts dans le fichier debian/control.
7.3. Vérification des scripts du responsable d'un paquet
Tous les scripts du responsable, (c'est-à-dire les fichiers
preinst, prerm, postinst et postrm), sont difficiles à écrire
correctement, à moins qu'ils n'aient été générés automatiquement
par les programmes debhelper. Ne les utilisez donc pas si vous
êtes un responsable débutant (consultez Section 5.18, «
{post,pre}{inst,rm} »).
Si le paquet utilise des scripts du responsable non triviaux,
veuillez les essayer non seulement pour le processus
d'installation, mais aussi les processus de suppression, purge et
mise à niveau. De nombreux bogues dans les scripts du responsable
surviennent lors de la suppression et de la purge. Utilisez la
commande dpkg comme ceci pour les essayer :
$ sudo dpkg -r gentoo
$ sudo dpkg -P gentoo
$ sudo dpkg -i gentoo_version-révision_i386.deb
Les séquences suivantes devraient être essayées :
* installation de la version précédente (si elle existe) ;
* mise à niveau depuis la version précédente ;
* rétrogradation (« downgrade ») à la version précédente
(optionnel) ;
* purge ;
* installation du nouveau paquet ;
* suppression (« remove ») du paquet ;
* nouvelle installation du paquet ;
* purge ;
Pour votre premier paquet, vous devriez créer des paquets
factices avec différentes versions pour essayer votre paquet à
l'avance et éviter des problèmes par la suite.
Gardez à l'esprit que si votre paquet a déjà été publié avec
Debian, des gens vont mettre à jour ce paquet à partir de la
version qui était dans la publication Debian précédente.
N’oubliez pas d'essayer aussi les mises à jour à partir de cette
version.
Même si la réinstallation vers une version antérieure n'est pas
officiellement gérée, il est préférable de la permettre.
7.4. Utilisation de lintian
Exécutez lintian(1) sur le fichier .changes. La commande lintian
exécute de nombreux scripts de tests pour vérifier la plupart des
erreurs habituelles d'empaquetage. ^[75]
$ lintian -i -I --show-overrides gentoo_0.9.12-1_i386.changes
Bien sûr, remplacez le nom de fichier par celui du fichier
.changes créé pour votre paquet. La sortie de la commande lintian
utilise les balises suivants :
* E: pour erreur ; une violation certaine de la Charte ou
erreur d'empaquetage ;
* W: pour avertissement ; une violation possible de la Charte
ou erreur d'empaquetage ;
* I: pour information ; une information sur certains aspects
d'empaquetage ;
* N: pour note ; un message détaillé pour vous aider à
déboguer ;
* O: pour ignoré ; un message ignoré par le fichier
lintian-overrides mais affiché avec le paramètre
--show-overrides.
En cas d'avertissements, mettez au point le paquet pour les
éviter ou vérifiez qu'ils sont infondés. S'ils sont infondés,
configurez les fichiers lintian-overrides comme décrit en
Section 5.14, « {paquet.,source/}lintian-overrides ».
Vous pouvez reconstruire le paquet avec dpkg-buildpackage et
lancer lintian en une seule commande, si vous utilisez debuild(1)
ou pdebuild(1).
7.5. Commande debc
La commande debc(1) permet d'énumérer les fichiers du paquet
Debian binaire.
$ debc paquet.changes
7.6. Commande debdiff
La commande debdiff(1) peut comparer les contenus de fichiers
entre deux paquets Debian source
$ debdiff ancien-paquet.dsc nouveau-paquet.dsc
La commande debdiff(1) permet aussi de comparer les listes de
fichiers entre deux ensembles de paquets Debian binaires.
$ debdiff ancien-paquet.changes nouveau-paquet.changes
Ces commandes sont utiles pour identifier ce qui a été modifié
dans les paquets source et pour vérifier d'éventuelles
modifications faites par inadvertance lors de la mise à jour des
paquets binaires, comme par exemple des fichiers déplacés ou
enlevés involontairement.
7.7. Commande interdiff
Vous pouvez comparer deux fichiers diff.gz avec la commande
interdiff(1). C'est utile pour vérifier qu'aucune modification
involontaire n'a été effectuée sur les sources par le responsable
en mettant à jour les paquets à l'ancien format source 1.0.
$ interdiff -z ancien-paquet.diff.gz nouveau-paquet.diff.gz
Le nouveau format source 3.0 garde les modifications dans
plusieurs fichiers de correctifs comme décrit en Section 5.25,
« patches/* ». Vous pouvez aussi suivre les modifications de tous
les fichiers debian/patches/* en utilisant interdiff.
7.8. Commande mc
Toutes ces opérations d'inspection de fichier peuvent être
transformées en un processus intuitif avec un gestionnaire de
fichiers comme mc(1) qui vous permet de consulter non seulement
le contenu des fichiers paquet *.deb, mais aussi les fichiers
*.udeb, *.debian.tar.gz, *.diff.gz et *.orig.tar.gz.
Soyez attentif aux fichiers inutiles ou de taille nulle, dans les
paquets binaires et source. Souvent les fichiers inutiles ne sont
pas nettoyés correctement ; adaptez le fichier rules pour
compenser.
---------------------------------------------------------------------
^[75] Il n'est pas nécessaire d'ajouter le paramètre -i -I
--show-overrides à lintian si vous avez personnalisé /etc/
devscripts.conf ou ~/.devscripts comme décrit en Section 6.3,
« Commande debuild ».
Chapitre 8. Mise à jour de paquet
La réécriture de ce tutoriel avec des contenus à jour et des
exemples pratiques supplémentaires est disponible sur Guide du
responsable Debian. Veuillez utiliser ce nouveau tutoriel comme
document principal.
Après la publication d'un paquet, il sera rapidement nécessaire
de le mettre à jour.
8.1. Nouvelle révision Debian
Soit un rapport de bogue numéroté #654321, concernant votre
paquet et décrivant un problème que vous pouvez résoudre. Voici
ce que vous devez faire pour créer une nouvelle révision du
paquet :
* pour un nouveau correctif :
+ configurer le nom du correctif : dquilt new
nomdubogue.patch,
+ déclarer le fichier à modifier : dquilt add fichier-bogué
,
+ corriger le problème dans le paquet source pour le bogue
amont,
+ l'enregistrer en nomdubogue.patch : dquilt refresh,
+ ajouter sa description : dquilt header -e ;
* pour la mise à jour d'un correctif :
+ rappeler le correctif toto.patch existant : dquilt pop
toto.patch,
+ corriger le problème dans l'ancien toto.patch,
+ mettre à jour toto.patch : dquilt refresh,
+ mettre à jour sa description : dquilt header -e,
+ appliquer tous les correctifs en enlevant les
approximations (fuzz) : while dquilt push; do dquilt
refresh; done ;
* ajouter une nouvelle révision au début du fichier changelog
Debian, par exemple avec dch -i, ou explicitement avec dch -v
version-révision, et ajoutez ensuite les commentaires en
utilisant votre éditeur favori ;^[76]
* ajouter une courte description du bogue et de la solution
dans l'entrée du changelog, suivie par Closes: #654321. De
cette manière, le rapport de bogue sera automagiquement fermé
par le logiciel de maintenance des archives une fois le
paquet accepté dans l'archive Debian ;
* répéter les opérations précédentes pour corriger plus de
bogues tout en mettant à jour le fichier changelog avec dch
selon votre besoin ;
* recommencer ce qui a été fait en Section 6.1,
« Reconstruction complète » et Chapitre 7, Contrôle des
erreurs du paquet ;
* une fois satisfait, modifier la valeur de distribution dans
changelog d'UNRELEASED à la valeur de distribution cible
unstable (ou même experimental) ; ^[77]
* envoyer le paquet comme en Chapitre 9, Envoi de paquet. La
différence est que cette fois, l'archive source originale ne
sera pas incluse, car elle n'a pas été modifiée et est déjà
dans l'archive Debian.
Un cas délicat peut se produire quand vous faites un paquet local
pour expérimenter l'empaquetage avant d'envoyer la version
normale vers l'archive officielle, par exemple 1.0.1-1. Pour des
mises à niveau plus en douceur, il vaut mieux créer une entrée de
changelog avec une chaîne de version comme 1.0.1-1~rc1. Vous
pouvez nettoyer le changelog en fusionnant ces entrées de
modification en une unique entrée pour le paquet officiel.
Consultez Section 2.6, « Nom et version de paquet » pour l'ordre
des chaînes de version.
8.2. Examen d'une nouvelle version amont
Lors de la préparation de paquets d'une nouvelle version amont
pour l'archive Debian, vous devez commencer par vérifier la
nouvelle version amont.
Commencez par lire les changelog et NEWS amonts, ainsi que toute
autre documentation distribuée avec la nouvelle version.
Examinez ensuite les modifications entre les anciennes et
nouvelles sources amont, pour guetter tout changement suspect :
$ diff -urN toto-ancienneversion toto-nouvelleversion
Les modifications de certains fichiers automatiquement créés par
Autotools comme missing, aclocal.m4, config.guess, config.h.in,
config.sub, configure, depcomp, install-sh, ltmain.sh et
Makefile.in peuvent être ignorées. Vous pouvez les effacer avant
d'exécuter diff pour examiner les sources.
8.3. Nouvelle version amont
Si un paquet toto est correctement empaqueté au nouveau format
3.0 (native) ou 3.0 (quilt), empaqueter une nouvelle version
amont consiste essentiellement à déplacer l'ancien répertoire
debian dans les nouvelles sources. Ce peut être réalisé en
exécutant tar xvzf /chemin/vers/toto_ancienneversion
.debian.tar.gz depuis la nouvelle arborescence source
décompressée. ^[78] Bien sûr, vous devez vous occuper de quelques
routines évidentes :
* création d'une copie des sources amont dans un fichier toto_
nouvelleversion.orig.tar.gz ;
* mise à jour du ficher changelog Debian avec dch -v
nouvelleversion-1 :
+ ajout d'une entrée avec New upstream release. (nouvelle
version amont),
+ description succincte des modifications dans la nouvelle
version amont qui corrigent des bogues et ferment les
rapports associés en ajoutant Closes: #numéro_de_bogue,
+ description succincte des modifications à la nouvelle
version amont par le responsable qui corrigent des bogues
et ferment les rapports associés en ajoutant Closes: #
numéro_de_bogue ;
* application de tous les correctifs en enlevant les
approximations (« fuzz ») : while dquilt push; do dquilt
refresh; done.
Si la fusion des correctifs ne s'applique pas proprement,
examinez la situation (des indices sont laissés dans les fichiers
.rej) :
* si un correctif appliqué aux sources a été intégré aux
sources amont :
+ dquilt delete pour l'enlever ;
* si un correctif appliqué aux sources entre en confit avec les
nouvelles modifications des sources amont :
+ dquilt push -f pour appliquer les anciens correctifs tout
en forçant les rejets comme truc.rej ;
+ édition manuelle du fichier truc pour obtenir le résultat
attendu de truc.rej ;
+ dquilt refresh pour mettre à jour le correctif ;
* continuer comme d'habitude avec while dquilt push; do dquilt
refresh; done.
Cette méthode peut être automatisée avec uupdate(1) :
$ apt-get source toto
...
dpkg-source: info: extraction de toto dans toto-ancienneversion
dpkg-source: info: extraction de toto_ancienneversion.orig.tar.gz
dpkg-source: info: extraction de toto_ancienneversion-1.debian.tar.gz
$ ls -F
toto-ancienneversion/
toto_ancienneversion-1.debian.tar.gz
toto_ancienneversion-1.dsc
toto_ancienneversion.orig.tar.gz
$ wget http://example.org/toto/toto-nouvelleversion.tar.gz
$ cd toto-ancienneversion
$ uupdate -v nouvelleversion ../toto-nouvelleversion.tar.gz
$ cd ../toto-nouvelleversion
$ while dquilt push; do dquilt refresh; done
$ dch
... documentation des modifications réalisées
Si le fichier debian/watch est configuré comme décrit en
Section 5.21, « watch », la commande wget est inutile. Exécutez
simplement uscan(1) dans le répertoire toto-ancienneversion à la
place de la commande uupdate. Les sources mises à jour seront
automagiquement recherchées, téléchargées, et la commande uupdate
sera exécutée. ^[79]
Vous pouvez publier ces sources mises à jour en recommençant ce
qui a été fait en Section 6.1, « Reconstruction complète »,
Chapitre 7, Contrôle des erreurs du paquet et Chapitre 9, Envoi
de paquet.
8.4. Mise à jour du style d'empaquetage
La mise à jour du style d'empaquetage n'est pas nécessaire lors
de la mise à jour d'un paquet. Néanmoins, le faire permet de
profiter de tout le potentiel du système debhelper moderne et du
format source 3.0 : ^[80]
* si vous devez, pour quelque raison que ce soit, recréer des
fichiers modèles qui avaient été effacés, vous pouvez
exécuter dh_make à nouveau depuis le répertoire des sources
Debian, avec l'option --addmissing. Puis modifiez-les de
façon adéquate ;
* si le paquet n'a pas été mis à jour pour utiliser la syntaxe
dh de debhelper v7+ dans le fichier debian/rules, mettez-le à
jour pour utiliser dh. Mettez à jour le fichier debian/
control en conséquence ;
* si vous voulez mettre à jour le fichier rules créé avec le
mécanisme d'héritage Makefile du système de compilation usuel
Debian (cdbs) vers la syntaxe dh, consultez les documents
suivants pour comprendre ses variables de configuration
DEB_* :
+ copie locale de /usr/share/doc/cdbs/cdbs-doc.pdf.gz,
+ le système de compilation usuel Debian (CDBS),
FOSDEM 2009 ;
* si vous avez un paquet source 1.0 sans fichier toto.diff.gz,
vous pouvez le mettre à jour au récent format source 3.0
(native) en créant debian/source/format contenant 3.0
(native). Le reste des fichiers debian/* peut être simplement
copié ;
* si vous avez un paquet source 1.0 avec un fichier toto
.diff.gz, vous pouvez le mettre à jour au récent format
source 3.0 (quilt) en créant debian/source/format contenant
3.0 (quilt). Le reste des fichiers debian/* peut être
simplement copié. Importez le fichier gros.diff créé par la
commande filterdiff -z -x '*/debian/*' toto.diff.gz >
gros.diff dans votre système quilt, au besoin ; ^[81]
* si l'empaquetage a été créé en utilisant un autre système de
correctif comme dpatch, dbs ou cdbs avec -p0, -p1 ou -p2,
convertissez-le à quilt avec deb3 disponible en http://
bugs.debian.org/581186 ;
* si l'empaquetage a été créé avec la commande dh et le
paramètre --with quilt ou les commandes dh_quilt_patch et
dh_quilt_unpatch, supprimez-le et utilisez le nouveau format
source 3.0 (native).
Vous devriez consulter les propositions d'améliorations Debian
(DEP — Debian Enhancement Proposals) et adopter les propositions
marquées « ACCEPTED ».
Les autres tâches décrites en Section 8.3, « Nouvelle version
amont » sont aussi à effectuer.
8.5. Conversion en UTF-8
Si les documents amonts sont encodés avec d'anciens jeux de
caractères, les convertir en UTF-8 peut être utile :
* avec iconv(1) pour convertir l'encodage de fichiers texte :
iconv -f latin1 -t utf8 truc_entrée.txt > truc_sortie.txt
* avec w3m(1) pour convertir les fichiers HTML en fichier texte
UTF-8. Assurez-vous d'exécuter cette commande avec des
paramètres régionaux en UTF-8 :
LC_ALL=en_US.UTF-8 w3m -o display_charset=UTF-8 \
-cols 70 -dump -no-graph -T text/html \
< truc_entrée.html > truc_sortie.txt
8.6. Rappels pour la mise à jour de paquets
Voici quelques rappels pour la mise à jour de paquets :
* préservez les anciennes entrées changelog (cela va de soi,
mais des personnes ont parfois utilisé dch au lieu de dch -i)
;
* les modifications Debian existantes doivent être réévaluées ;
jetez tout ce qui a été incorporé en amont (sous une forme ou
une autre), et souvenez-vous de garder ce qui ne l'a pas été,
à moins qu'il n'y ait une bonne raison de ne pas le faire ;
* si le système de construction a été modifié (avec un peu de
chance, vous êtes au courant depuis l'inspection des
modifications amont), mettez à jour les dépendances de
construction debian/rules et debian/control, si besoin est ;
* vérifiez dans le système de gestion de bogues (BTS) que
personne n'a fourni de correctifs aux bogues ouverts ;
* vérifiez le contenu du fichier .changes pour vous assurer que
vous envoyez vers la bonne distribution, que les rapports de
bogue refermés sont correctement listés dans les champs
Closes, que les champs Maintainer et Changed-By
correspondent, que le fichier est signé avec GPG, etc.
---------------------------------------------------------------------
^[76] Pour obtenir la date au format voulu, utilisez LANG=C date
-R.
^[77] Si vous utilisez la commande dch -r pour faire cette
dernière modification, n'oublier pas de sauver le fichier
changelog explicitement dans l'éditeur.
^[78] Si un paquet toto est empaqueté avec l'ancien format 1.0,
ce peut plutôt être réalisé en exécutant zcat /chemin/vers/toto_
ancienneversion.diff.gz|patch -p1 depuis la nouvelle arborescence
source décompressée.
^[79] Si la commande uscan télécharge les sources mises à jour
mais n'exécute pas la commande uupdate, vous devriez corriger le
fichier debian/watch pour avoir debian uupdate après l'URL.
^[80] Si votre parrain ou d'autres responsables s'opposent à la
mise à jour du style d'empaquetage existant, ne vous embêtez pas
à argumenter. Il y a des choses plus importantes à faire.
^[81] vous pouvez découper gros.diff en plusieurs petits
correctifs incrémentaux avec la commande splitdiff.
Chapitre 9. Envoi de paquet
La réécriture de ce tutoriel avec des contenus à jour et des
exemples pratiques supplémentaires est disponible sur Guide du
responsable Debian. Veuillez utiliser ce nouveau tutoriel comme
document principal.
Debian now requires source-only uploads for normal upload. So
this page is outdated.
Maintenant que votre nouveau paquet a été testé en détail, vous
voulez le publier sur une archive publique afin de le partager.
9.1. Envoi vers l'archive Debian
Une fois devenu un développeur Debian officiel, ^[82] vous pouvez
envoyer le paquet sur les archives Debian. ^[83] Vous pouvez le
faire vous-même, mais il est plus facile d'utiliser les outils
automatiques existants, comme dupload(1) ou dput(1). Nous
décrirons la façon de faire avec dupload. ^[84]
D'abord vous devez écrire le fichier de configuration de dupload.
Vous pouvez soit éditer le fichier global /etc/dupload.conf, soit
avoir votre propre fichier ~/.dupload pour remplacer les quelques
détails que vous voulez changer.
Vous pouvez lire la page de manuel dupload.conf(5) pour
comprendre ce que chacune de ces options signifie.
L'option $default_host détermine la file de téléchargement qui
sera utilisée par défaut. anonymous-ftp-master est la principale,
mais il est possible que vous souhaitiez en utiliser une autre. ^
[85]
Une fois connecté à Internet, vous pouvez envoyer le paquet :
$ dupload gentoo_0.9.12-1_i386.changes
dupload vérifie que les sommes SHA1 et SHA256 des fichiers
correspondent à celles du fichier .changes. Dans le cas
contraire, un avertissement proposera de le reconstruire comme
décrit en Section 6.1, « Reconstruction complète » pour pouvoir
téléverser le fichier correctement.
Si vous rencontrez un problème d'envoi à ftp://
ftp.upload.debian.org/pub/UploadQueue/, vous pouvez le résoudre
manuellement en envoyant un fichier *.commands signé avec GPG à
ftp://ftp.upload.debian.org/pub/UploadQueue/ avec ftp. ^[86] Par
exemple en utilisant hello.commands :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Uploader: Machin Bidule <Machin.Bidule@example.org>
Commands:
rm hello_1.0-1_i386.deb
mv hello_1.0-1.dsx hello_1.0-1.dsc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
[...]
-----END PGP SIGNATURE-----
9.2. Inclusion de orig.tar.gz pour l'envoi
Lors du premier envoi d'un paquet vers l'archive, il faut aussi
inclure les sources orig.tar.gz d'origine. Si le numéro de
révision Debian de ce paquet n'est ni 1 ni 0, vous devez passer
l'option -sa à la commande dpkg-buildpackage.
Pour la commande dpkg-buildpackage :
$ dpkg-buildpackage -sa
Pour la commande debuild :
$ debuild -sa
Pour la commande pdebuild :
$ pdebuild --debbuildopts -sa
D'un autre côté, l'option -sd forcera l'exclusion des sources
orig.tar.gz originales.
9.3. Versions non envoyées
Si vous créez plusieurs enregistrements dans debian/changelog en
omettant des téléversements, vous devez créer un fichier
*_.changes approprié incluant toutes les modifications depuis le
dernier envoi. Cela peut être fait avec l'option -v de
dpkg-buildpackage suivie de la version, par exemple 1.2.
Pour la commande dpkg-buildpackage :
$ dpkg-buildpackage -v1.2
Pour la commande debuild :
$ debuild -v1.2
Pour la commande pdebuild :
$ pdebuild --debbuildopts "-v1.2"
---------------------------------------------------------------------
^[82] Consultez Section 1.1, « Dynamique sociale de Debian ».
^[83] Des archives publiquement accessibles comme http://
mentors.debian.net/ qui fonctionnent à peu près de la même façon
que l'archive Debian fournissent un espace d'envoi accessible
publiquement aux non-DD (développeurs Debian). Vous pouvez
configurer vous-même une archive équivalente en utilisant les
outils de http://wiki.debian.org/HowToSetupADebianRepository.
Cette section est donc utile aussi aux non-DD.
^[84] Le paquet dput semble fournir plus de fonctionnalités, et
devient plus populaire que le paquet dupload. Il utilise le
fichier /etc/dput pour la configuration globale et le fichier ~
/.dput.cf pour la configuration par utilisateur. Il gère aussi
d’origine les services relatifs à Ubuntu.
^[85] Consultez la référence du Développeur Debian, 5.6. « Envois
de paquets ».
^[86] Consultez ftp://ftp.upload.debian.org/pub/UploadQueue/
README. Vous pouvez aussi utiliser la commande dcut du paquet
dput.
Annexe A. Empaquetage avancé
La réécriture de ce tutoriel avec des contenus à jour et des
exemples pratiques supplémentaires est disponible sur Guide du
responsable Debian. Veuillez utiliser ce nouveau tutoriel comme
document principal.
Voici quelques conseils et indications pour des sujets
d'empaquetage avancé auxquels vous serez sans doute confrontés.
La lecture de toutes les références suggérées ici est vivement
recommandée.
Vous pouvez avoir besoin d’éditer vous-mêmes les fichiers de
modèle d’empaquetage produits par la commande dh_make pour
répondre à des préoccupations de ce chapitre. La nouvelle
commande debmake devrait le faire de meilleure façon.
A.1. Bibliothèques partagées
Avant d'empaqueter des bibliothèques partagées, vous devriez lire
les références essentielles suivantes avec attention :
* Charte Debian, 8 « Bibliothèques partagées » ;
* Charte Debian, 9.1.1 « Structure de système de fichiers » ;
* Charte Debian, 10.2 « Bibliothèques ».
Voici quelques conseils simplifiés à l'extrême pour commencer :
* les bibliothèques partagées sont des fichiers objet ELF
contenant du code compilé ;
* les bibliothèques partagées sont distribuées en fichiers *.so
(pas en fichiers *.a ni en fichiers *.la) ;
* les bibliothèques partagées sont surtout utilisées pour
partager du code commun à plusieurs exécutables avec le
mécanisme ld ;
* les bibliothèques partagées sont parfois utilisées pour
fournir plusieurs greffons à un exécutable avec le mécanisme
dlopen ;
* les bibliothèques partagées exportent des symboles qui
représentent des objets compilés comme des variables, des
fonctions et des classes ; elles permettent qu’on y accède à
partir des exécutables liés ;
* le SONAME d'une bibliothèque partagée libtruc.so.1 : objdump
-p libtruc.so.1 | grep SONAME ;^[87]
* le SONAME d'une bibliothèque partagée correspond normalement
au nom du fichier de bibliothèque (mais pas toujours) ;
* le SONAME d'une bibliothèque partagée liée à /usr/bin/truc :
objdump -p /usr/bin/truc | grep NEEDED ;^[88]
* libtruc1 : le paquet de bibliothèque pour la bibliothèque
partagée libtruc.so.1 avec la version 1 d'ABI SONAME ;^[89]
* les scripts du responsable du paquet de bibliothèque doivent
appeler ldconfig dans des circonstances particulières pour
créer les liens symboliques nécessaires au SONAME ;^[90]
* libtruc1-dbg : le paquet de symboles de débogage qui contient
les symboles de débogage du paquet de bibliothèque partagée
libtruc1 ;
* libtruc-dev : le paquet de développement qui contient les
fichiers d'en-têtes, etc., de la bibliothèque partagée lib
truc.so.1 ;^[91]
* les paquets Debian ne devraient normalement pas contenir de
fichiers d'archive Libtool *.la ;^[92]
* les paquets Debian ne devraient normalement pas utiliser
RPATH ;^[93]
* bien qu'il soit dépassé et que ce ne soit qu'une référence
secondaire, le guide d'empaquetage de bibliothèques Debian
peut encore être utile.
A.2. Gestion de debian/paquet.symbols
Lors de l'empaquetage d'une bibliothèque partagée, il faut créer
un fichier debian/paquet.symbols pour gérer la version minimale
associée à chaque symbole pour les modifications d'ABI
rétrocompatibles sous le même SONAME de la bibliothèque pour le
même nom de paquet de bibliothèque partagée.^[94] Vous devriez
lire les références essentielles suivantes avec attention :
* Charte Debian, 8.6.3 « Le système de symboles » ;^[95]
* dh_makeshlibs(1) ;
* dpkg-gensymbols(1) ;
* dpkg-shlibdeps(1) ;
* deb-symbols(5).
Voici un exemple grossier de la manière de créer le paquet
libtruc1 à partir de la version amont 1.3 avec le fichier debian/
libtruc1.symbols adéquat :
* préparer le squelette d'arborescence source Debian en utilisant
le fichier amont libtruc-1.3.tar.gz :
+ s'il s'agit du premier empaquetage du paquet libtruc1, créer
le fichier vide debian/libtruc1.symbols ;
+ si la version amont précédente 1.2 a été empaquetée en tant
que paquet libtruc1 contenant le fichier debian/
libtruc1.symbols adéquat dans son paquet source, le
réutiliser ;
+ si la version amont précédente 1.2 n'a pas été empaquetée
avec le fichier debian/libtruc1.symbols adéquat, le créer
comme fichier symbols à partir de tous les paquets binaires
disponibles de même nom de paquet de bibliothèque partagée
contenant le même SONAME de la bibliothèque, par exemple de
versions 1.1-1 et 1.2-1 :^[96]
$ dpkg-deb -x libtruc1_1.1-1.deb libtruc1_1.1-1
$ dpkg-deb -x libtruc1_1.2-1.deb libtruc1_1.2-1
$ : > symbols
$ dpkg-gensymbols -v1.1 -plibtruc1 -Plibtruc1_1.1-1 -Osymbols
$ dpkg-gensymbols -v1.2 -plibtruc1 -Plibtruc1_1.2-1 -Osymbols
* essayer de construire depuis l'arborescence source avec des
outils comme debuild et pdebuild (en cas d'échecs dus à des
symboles manquants, etc., c'est qu'il y a eu des modifications
d'ABI non rétrocompatibles qui nécessitent de changer le nom de
paquet de bibliothèque partagée en quelque chose comme libtruc1a
avant de recommencer) :
$ cd libtruc-1.3
$ debuild
...
dpkg-gensymbols: warning: some new symbols appeared in the symbols file: ...
see diff output below
--- debian/libtruc1.symbols (libtruc1_1.3-1_amd64)
+++ dpkg-gensymbolsFE5gzx 2012-11-11 02:24:53.609667389 +0900
@@ -127,6 +127,7 @@
truc_get_name@Base 1.1
truc_get_longname@Base 1.2
truc_get_type@Base 1.1
+ truc_get_longtype@Base 1.3-1
truc_get_symbol@Base 1.1
truc_get_rank@Base 1.1
truc_new@Base 1.1
...
* si un différentiel est affiché par dpkg-gensymbols comme
ci-dessus, extraire le fichier symbols adéquat mis à jour du
paquet binaire généré de la bibliothèque partagée :^[97]
$ cd ..
$ dpkg-deb -R libtruc1_1.3_amd64.deb libtruc1-tmp
$ sed -e 's/1\.3-1/1\.3/' libtruc1-tmp/DEBIAN/symbols \
>libtruc-1.3/debian/libtruc1.symbols
* construire les paquets pour la publication avec des outils comme
debuild et pdebuild :
$ cd libtruc-1.3
$ debuild -- clean
$ debuild
...
En plus des exemples précédents, il faut vérifier plus
profondément la compatibilité d'ABI et changer vous-même les
versions de certains symboles si nécessaire. ^[98]
Bien que ce ne soit qu'une référence secondaire, le wiki Debian
sur l'utilisation de fichiers symboles et les pages web qui y
sont liées peuvent être utiles.
A.3. Multiarchitecture
La fonctionnalité de multiarchitecture introduite dans Debian
Wheezy intègre la prise en charge pour l'installation
interarchitecture de paquets binaires (en particulier entre i386
et amd64, mais aussi d'autres combinaisons) dans dpkg et apt.
Vous devriez lire les références suivantes avec attention :
* wiki Ubuntu sur la spécification multiarchitecture (amont) ;
* wiki Debian sur le multiarchitecture et son implémentation
(situation dans Debian).
Elle utilise un triplet du style i386-linux-gnu et
x86_64-linux-gnu pour le chemin d'installation des bibliothèques
partagées. Le chemin de triplet réel est défini dynamiquement
dans la variable $(DEB_HOST_MULTIARCH) par la commande
dpkg-architecture(1) pour chaque construction de paquet binaire.
Par exemple, le chemin d'installation de bibliothèques
multiarchitectures est modifié comme suit :^[99]
+---------------------------------------------------------------+
| Ancien |Chemin multiarchitecture |Chemin multiarchitecture |
| chemin | i386 | amd64 |
|-----------+-------------------------+-------------------------|
|/lib/ |/lib/i386-linux-gnu/ |/lib/x86_64-linux-gnu/ |
|-----------+-------------------------+-------------------------|
|/usr/lib/ |/usr/lib/i386-linux-gnu/ |/usr/lib/x86_64-linux-gnu|
| | |/ |
+---------------------------------------------------------------+
Voici quelques exemples typiques de scénarios de découpage de
paquet multiarchitecture pour les paquets suivants :
* une bibliothèque source libtruc-1.tar.gz ;
* un outil source bidule-1.tar.gz écrit en langage compilé ;
* un outil source machin-tar.gz écrit en langage interprété :
+---------------------------------------------------------------+
| Paquet |Architecture|Multi-Arch| Contenu du paquet |
|-------------+------------+----------+-------------------------|
|libtruc1 |any |same |la bibliothèque partagée,|
| | | |co-installable |
|-------------+------------+----------+-------------------------|
| | | |les symboles de débogage |
|libtruc1-dbg |any |same |de bibliothèque partagée,|
| | | |co-installable |
|-------------+------------+----------+-------------------------|
| | | |les fichiers d'en-tête, |
|libtruc-dev |any |same |etc., de bibliothèque |
| | | |partagée, co-installable |
|-------------+------------+----------+-------------------------|
| | | |les programmes de prise |
|libtruc-tools|any |foreign |en charge en cours |
| | | |d'exécution, non |
| | | |co-installable |
|-------------+------------+----------+-------------------------|
| | | |les fichiers de |
|libtruc-doc |all |foreign |documentation de |
| | | |bibliothèque partagée |
|-------------+------------+----------+-------------------------|
| | | |les fichiers du programme|
|bidule |any |foreign |compilé, non |
| | | |co-installable |
|-------------+------------+----------+-------------------------|
| | | |les fichiers de |
|bidule-doc |all |foreign |documentation du |
| | | |programme |
|-------------+------------+----------+-------------------------|
|machin |all |foreign |les fichiers du programme|
| | | |interprété |
+---------------------------------------------------------------+
Veuillez remarquer que le paquet de développement devrait
contenir un lien symbolique vers la bibliothèque partagée
associée sans numéro de version. Par exemple : /usr/lib/
x86_64-linux-gnu/libtruc.so → libtruc.so.1.
A.4. Construction d'un paquet de bibliothèque partagée
Un paquet de bibliothèque partagée peut être construit en
activant la prise en charge multiarchitecture en utilisant dh(1)
comme ceci :
* mettre à jour debian/control :
+ ajouter Build-Depends: debhelper (>=10) à la section du
paquet source,
+ ajouter Pre-Depends: ${misc:Pre-Depends} pour chaque paquet
binaire de bibliothèque partagée,
+ ajouter la définition Multi-Arch: à chaque section de paquet
binaire ;
* définir debian/compat à « 10 » ;
* ajuster le chemin classique /usr/lib/ en /usr/lib/$
(DEB_HOST_MULTIARCH)/ multiarchitecture pour tous les scripts
d'empaquetage :
+ appeler d'abord DEB_HOST_MULTIARCH ?= $(shell
dpkg-architecture -qDEB_HOST_MULTIARCH) dans debian/rules
pour définir la variable DEB_HOST_MULTIARCH,
+ remplacer /usr/lib/ par /usr/lib/$(DEB_HOST_MULTIARCH)/ dans
debian/rules,
+ si ./configure est utilisé par la cible
override_dh_auto_configure dans debian/rules, assurez-vous de
le remplacer par dh_auto_configure --, ^[100]
+ remplacer toutes les occurrences de /usr/lib/ par /usr/lib/*/
dans les fichiers debian/truc.install ;
+ générer les fichiers comme debian/truc.links à partir de
debian/truc.links.in dynamiquement en ajoutant un script à la
cible override_dh_auto_configure dans debian/rules :
override_dh_auto_configure:
dh_auto_configure
sed 's/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/g' \
debian/truc.links.in > debian/truc.links
Veuillez vous assurer d'avoir vérifié que le paquet de
bibliothèque partagée ne contient que les fichiers attendus, et
que le paquet -dev fonctionne toujours.
Tous les fichiers installés simultanément par des paquets
multiarchitectures au même endroit devraient avoir exactement le
même contenu. Vous devez faire attention aux différences générées
par l'ordre des octets de données (boutisme) et par les
algorithmes de compression.
A.5. Paquet Debian natif
Si un paquet est maintenu uniquement pour Debian ou simplement
pour un usage local, ses sources peuvent contenir tous les
fichiers debian/*. Il existe deux façons de l’empaqueter.
Vous pouvez créer l’archive amont en excluant les fichiers debian
/* et l’empaqueter comme un paquet Debian non natif comme dans
Section 2.1, « Processus de construction de paquet Debian ».
C’est la méthode normale que certaines personnes préconisent
d’utiliser.
L’autre méthode est d’utiliser la manière de procéder pour un
paquet Debian natif.
* créer le paquet source Debian natif au format 3.0 (native) en
utilisant un seul fichier tar compressé où tous les fichiers
sont intégrés :
+ paquet_version.tar.gz
+ paquet_version.dsc
* construire les paquets binaires Debian à partir du paquet
source Debian natif :
+ paquet_version_arch.deb
Par exemple, si vous avez des fichiers source dans ~/
mypackage-1.0 sans les fichiers debian/*, vous pouvez créer un
paquet natif Debian en utilisant la commande dh_make comme suit :
$ cd ~/monpaquet-1.0
$ dh_make --native
Alors le répertoire debian et son contenu sont créés comme en
Section 2.8, « Paquet Debian non natif initial ». Aucune archive
compressée n'est créée puisqu'il s'agit d'un paquet Debian natif,
mais c'est la seule différence. La suite de l'empaquetage est à
peu près similaire.
Après exécution de la commande dpkg-buildpackage, les fichiers
suivants apparaîtront dans le répertoire parent :
* monpaquet_1.0.tar.gz
c'est l'archive compressée du code source créé à partir du
répertoire monpaquet-1.0 par la commande dpkg-source (il ne
se termine pas par orig.tar.gz) ;
* monpaquet_1.0.dsc
c'est un résumé du contenu du code source comme dans un
paquet Debian non natif (il n'y a pas de révision Debian) ;
* monpaquet_1.0_i386.deb
c'est le paquet binaire terminé comme dans un paquet Debian
non natif (il n'y a pas de révision Debian) ;
* monpaquet_1.0_i386.changes
ce fichier décrit toutes les modifications effectuées dans la
version actuelle du paquet comme dans un paquet Debian non
natif (il n'y a pas de révision Debian).
---------------------------------------------------------------------
^[87] Alternative : readelf -d libtruc.so.1 | grep SONAME.
^[88] Alternative : readelf -d libtruc.so.1 | grep NEEDED.
^[89] Consultez la Charte Debian, 8.1 « Bibliothèques partagées
au moment de l'exécution ».
^[90] Consultez la Charte Debian, 8.1.1 « ldconfig ».
^[91] Consultez la Charte Debian, 8.3 « Bibliothèques statiques »
et la Charte Debian, 8.4 « Fichiers de développement ».
^[92] Consultez le wiki Debian sur l'objectif de publication
relatif à la suppression des fichiers *.la.
^[93] Consultez le wiki Debian sur les problèmes avec RPATH*.la.
^[94] Les modifications d'ABI non rétrocompatibles devraient
normalement nécessiter une mise à jour du SONAME de la
bibliothèque et du nom de paquet de la bibliothèque partagée.
^[95] Pour les bibliothèques C++ et d'autres cas lorsque le suivi
de symboles individuels est trop compliqué, suivez plutôt la
Charte Debian, 8.6.4 « Le système de shlibs ».
^[96] Toutes les versions précédentes des paquets Debian sont
disponibles sur http://snapshot.debian.org/. La révision Debian
est supprimée de la version pour faciliter le rétroportage du
paquet : 1.1 << 1.1-1~bpo70+1 << 1.1-1 et 1.2 << 1.2-1~bpo70+1 <<
1.2-1
^[97] La révision Debian est supprimée de la version pour
faciliter le rétroportage du paquet : 1.1 << 1.3 << 1.3-1~bpo70+1
<< 1.3-1
^[98] Consultez la Charte Debian, 8.6.2 « Modifications d'ABI
dans les bibliothèques partagées ».
^[99] Certains anciens chemins de bibliothèques particulières
comme /lib32/ et /lib64/ ne sont plus utilisés.
^[100] Sinon, les arguments --libdir=\$${prefix}/lib/$
(DEB_HOST_MULTIARCH) et --libexecdir=\$${prefix}/lib/$
(DEB_HOST_MULTIARCH) peuvent être ajoutés à ./configure. Veuillez
remarquer que --libexecdir indique le chemin par défaut pour
installer les programmes exécutables démarrés par d'autres
programmes plutôt que par des utilisateurs. Sa valeur Autotools
par défaut est /usr/libexec/ mais sa valeur Debian par défaut est
/usr/lib/.