Le manuel de programmation de dpkg <author>D. Cure <email>cure@cnam.fr <author>C. Jacolot <email>jacolot@ubolib.univ-brest.fr <version><date> <abstract> Ce manuel décrit les aspects techniques de la création des paquetages Debian source et binaire. Il documente l'interface entre dselect et ces scriptes d'accès. Il ne donne aucun renseignement sur le Projet Debian et vous devez connaître les fonctions de dpkg dans la perspective d'administration. <copyright>Copyright ©1996 Ian Jackson <copyright>Copyright ©1997 David Curé et Christian Jacolot pour la version française. Ce manuel est un logiciel libre; vous pouvez le distribuer et/ou le modifier suivant les termes de la GNU General Public License publiée par la Free Software Foundation; en version 2 ou ultérieure. Il est distribué dans l'espoir d'être utile, mais sans garantie. Lire la GNU General Public License pour plus de détails. Vous devez avoir reçu une copie de la GNU General Public License avec votre système Debian GNU/Linux, dans le répertoire <tt>/usr/doc/copyright/GPL</>, ou avec les sources du paquetage dpkg dans le fichier COPYING. Si ce n'est pas le cas, vous pouvez écrire à la Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. <toc sect> <chapt id="intro">Introduction et limites de ce manuel <prgn/dpkg/ est un ensemble de programmes de création, d'installation et de destruction des fichiers de paquet binaire sur les systèmes Unix <footnote><prgn/dpkg/ est conçu à la base pour Linux/GNU Debian, mais peut fonctionner ou être porté sur d'autres systèmes</footnote>. Les paquets binaires sont conçus pour la gestion des programmes exécutables (c'est à dire des binaires compilés) et leurs données associées, bien que les exemples de code source et la documentation fassent parties de certains paquets. Ce manuel décrit les aspects techniques de création des paquets binaires de la Debian (fichiers <tt>.deb</>). Il documente le comportement des programmes de gestion des paquets <prgn/dpkg/, <prgn/dselect/ et autres, et la manière dont ils interagissent avec les paquets. Il précise aussi les interactions entre le noyau <prgn/dselect/ et les scripts de méthodes d'accès qu'il utilise pour installer réellement les paquets sélectionnés, et décrit comment créer une nouvelle méthode d'accès. Ce manuel ne détaille pas les options et l'utilisation des outils de création et d'installation des paquets. Il serait donc souhaitable de le lire conjointement avec les pages de manuels de ces programmes. Les programmes utilitaires qui sont fournis avec <prgn/dpkg/ pour gérer la configuration des différents systèmes et problèmes similaires, tels que <prgn/update-rc.d/ et <prgn/install-info/ ne sont pas non plus décrits en détail, il faut faire référence à leurs pages de manuel. Ce manuel ne décrit pas les principes imposés aux paquets Debian, tels que les permissions sur les fichiers et répertoires, la documentation, les procédures de chargement, etc. Il est donc préférable d'avoir recours au manuel des principes pour les paquets Debian pour ces détails (beaucoup d'entre eux sont appréciables même si tu ne penses pas charger ton paquet et le rendre disponible dans une distribution). On supposera que le lecteur est familier avec le manuel de l'administrateur système <prgn/dpkg/. Malheureusement ce document n'existe pas encore. La version Debian du programme <prgn/hello/ du GNU/FSF est fourni comme exemple pour les personnes qui souhaitent créer des paquets Debian. Le paquet Debian <prgn/debmake/ est un outil recommandé, appréciable pour la création et la maintenance des paquets Debian. Cependant, bien que les outils et les exemples soient utiles, ils nécessitent tout de même de lire et de suivre les manuels du programmeur et des principes. <chapt id="paquetsbinaires">Les paquets binaires Un paquet binaire a deux sections principales. La première partie consiste en divers fichiers d'information de contrôle et des scripts utilisés par dpkg lors de l'installation et de la désinstallation. Voir <ref id="paquetsbinaires-2">. La deuxième partie est une archive contenant les fichiers et les répertoires à installer. Dans le futur, les paquets binaires pourront contenir d'autres composants, comme des sommes de contrôles ou des signatures numériques. Le format de l'archive est décrit en entier dans la page du manuel <manref name="deb" section="5">. <sect id="paquetsbinaires-1">Création des paquets binaires - dpkg-deb Toutes les manipulations de paquets binaires se font avec <prgn/dpkg-deb/; c'est le seul programme qui connaisse le format. (<prgn/dpkg-deb/ sera exécuté par l'appel de <prgn/dpkg/, si <prgn/dpkg/ reconnaît que les paramètres qui lui sont passés sont pour <prgn/dpkg-deb/ et l'exécutera avec les mêmes paramètres). De manière à créer un paquet binaire, tu dois créer une arborescence qui contient tous les fichiers et répertoires que tu veux retrouver dans les données du système de fichier du paquet. Dans les paquets Debian format source, ce répertoire est habituellement <tt>debian/tmp</>, par rapport à la racine de l'arborescence du paquet source. Ils doivent avoir l'emplacement (par rapport à la racine de l'arborescence que tu construis), le propriétaire et les permissions que tu veux leur assigner sur le système quand ils sont installés. Dans la version courante de <tt>dpkg</>, l'uid (ou nom de l'utilisateur) et le gid (ou le nom du groupe) pour les utilisateurs et les groupes utilisés doivent être les mêmes sur le système où le paquet est construit et sur le système où il sera installé. Tu dois ajouter un répertoire spécial à la racine de cette mini arborescence que tu as créée: <tt>DEBIAN</>. Il doit contenir les fichiers de contrôle d'information, notamment le fichier de contrôle des paquets binaires (voir <ref id="paquetsbinaires-3">). Le répertoire <tt>DEBIAN</> n'apparaîtra pas dans l'archive du système de fichiers du paquet, et ainsi ne sera pas crée quand le paquet sera installé. Quand tu prépares, tu dois appeler: <example> dpkg --build directory </example> Cette commande construit le paquet dans directory</><tt>.deb</> (<tt>dpkg</> sait que <tt>--built</> est une option de <tt>dpkg-deb</>, donc il appelle <tt>dpkg-deb</> avec les mêmes arguments pour construire le paquet.) Voir les pages de manuel <manref name="dpkg-deb" section="8"> sur les détails pour savoir comment examiner le contenu de ce fichier fraîchement créé. Tu trouveras les sorties des commandes suivantes intéressantes: <example> dpkg-deb --info nomdefichier</>.deb dpkg-deb --contents nomdefichier</>.deb dpkg --contents nomdefichier</>.deb </example> Pour voir le fichier copyright d'un paquet, tu peux utiliser la commande: <example> dpkg --fsys-tarfile nomdufichier</>.deb | tar xof usr/doc/\*copyright | less </example> ***************************************************************** <sect id="paquetsbinaires-2">Les fichiers d'information de contrôle de paquet Le partie d'information de contrôle d'un paquet binaire est une collection de fichiers avec des noms connus de <tt>dpkg</>. Il traitera le contenu de ces fichiers d'une manière spéciale - certains d'entre eux contiennent des informations utilisées par <tt>dpkg</> quand il installe ou enlève le paquet; les autres sont des script que le mainteneur du paquet veut que <tt>dpkg</> exécute. Il est possible de mettre d'autres fichiers dans la zone de contrôle du paquet, mais ce n'est pas généralement une bonne idée (de toute façon ils seront ignorés). Voici une liste brève de fichiers d'information de contrôle utilisés par <tt>dpkg</> et un résumé de ce qu'ils fonts. <taglist> <tag><tt/control/ <item>C'est le fichier clé de description utilisé par <tt>dpkg</>. Il spécifie le nom et la version du paquet, donne sa description pour les utilisateur, établit les relations avec les autres paquets, etc. Voir <ref id="paquetsbinaires-3">. Il est habituellement généré automatiquement à partir des informations du paquet source par le programme <tt>dpkg-gencontrol</> et avec l'aide de <tt>dpkg-shlibdeps</>. Voir <ref id="paquetssources-1">. <tag><tt>postinst, preinst, postrm, prerm</> <item>Ce sont des fichiers exécutables (habituellement des scripts) que <tt>dpkg</> démarre pendant l'installation, la mise à jour ou l'effacement des paquets. Ils permettent au paquet de traiter les choses qui lui sont particulières ou qui nécessitent un traitement plus compliqué que celui fourni par <tt>dpkg</>. Les détails de quand et comment ils sont appelés, sont indiqués dans les scripts de maintenance des paquets et la procédure d'installation voir <ref id="scriptmaintenance">. Il est très important de rendre ces scripts idempotents <footnote>Ce qui signifie que s'ils sont lancés plusieurs fois ou s'ils échouent et que tu les appelles de nouveau, ils ne doivent pas se planter, mais juste s'assurer que tout est à sa place.</footnote>. Si une erreur survient, l'utilisateur interrompt <tt>dpkg</> ou si d'autres problèmes se produisent, tu ne laisses pas l'utilisateur avec un paquet inutilisable. Les scripts de maintenance sont garantis pour fonctionner avec un terminal de contrôle et peuvent interagir avec l'utilisateur. S'ils ont besoins de demander les mots de passe, utilise une interaction plein écran ou quelque chose de similaire, tu dois faire cela vers et à partir de <tt>/dev/tty</>, étant donné que <tt>dpkg</> redirigera à certains points les entrées/sorties standards du script afin d'enregistrer la procédure d'installation. Cependant, car ces scripts doivent être exécutés sur la sortie standard redirigée dans un tube pour les besoins d'enregistrement, les scripts Perl doivent être non bufférisés en sortie en indiquant <tt>$|=1</> afin que la sortie soit imprimée immédiatement plutôt que d'être bufférisé. Chaque script doit retourner zéro pour un succès ou autre chose que zéro pour un échec. <tag><tt>conffiles</> <item>Ce fichier contient une liste de fichiers de configuration qui doivent être manipulés automatiquement par <tt>dpkg</> (voir <ref id="fichiersconf">). Note que tous les fichiers de configuration ne sont pas forcément listés ici. <tag><tt>shlibs</> <item>Ce fichier contient une liste des librairies partagées fourni par le paquet avec les détails des dépendances pour chacune. Il est utilisé par <tt>dpkg-shlibdeps</> quand il détermine quelles dépendances sont nécessaires dans un fichier de contrôle de paquet. Le format du fichier <tt>shlibs</> est décrit dans <ref id="libpartages-1">. </taglist> <sect id="paquetsbinaires-3">Le fichier principal d'information de contrôle: control Le fichier d'information de contrôle le plus important utilisé par <tt>dpkg</> quand il installe un paquet est <tt>control</>. Il contient toutes les statistiques vitales du paquet. Les fichiers d'information de contrôle des paquets binaires construits à partir des sources Debian sont faits par un outil spécial <tt>dpkg- gencontrol</> qui lit <tt>debian/control</> et <tt>debian/changelog</> pour trouver les informations dont il a besoin. voir <ref id="paquetssources"> pour plus de détails. Les champs dans les fichiers de contrôle des paquets binaires est: <taglist> <tag><tt>Package</> <item>(obligatoire) <tag><tt>Version</> <item>(obligatoire) <tag><tt>Architecture</> <item>(obligatoire<footnote>Ce champ apparaît dans tous les paquets, même si <tt>dpkg</> n'en as pas besoin, afin que les vieux paquets puissent être toujours installés.</footnote>) <tag><tt>Depends, Provides</> <item>et al. <tag><tt>Essential</> <item> <tag><tt>Maintener</> <item> <tag><tt>Section, Priority</> <item> <tag><tt>Source</> <item> <tag><tt>Description</> <item> <tag><tt>Installed-Size</> <item> </taglist> Une description de la syntaxe des fichiers de contrôle et le but de ces champs sont disponibles dans <ref id="fichierscontroles">. <chapt id="paquetssources">Les paquets sources Dans la distribution Debian, les paquets binaires sont générés à partir des sources Debian, qui sont dans un format spécial pour faciliter la construction automatique des binaires. Il y avait une version précédente d'un format source Debian qui est obsolète. Les instructions pour convertir les vieux paquets sont données dans le manuel des principes Debian. <sect id="paquetssources-1">Les outils pour manipuler les paquets sources De nombreux outils sont fournis pour manipuler les paquets sources. Ils emballent et déballent les sources et aident à la construction des paquets binaires et à gérer la distribution des nouvelles versions. Le manuel présente une introduction et un exemple d'utilisation courante de ces outils, pour avoir de plus amples informations sur leurs options et leurs opérations, voir <manref name="dpkg-source" section="1">. Le paquet <prgn/hello/ est un exemple de construction de paquet source Debian et de mise en oeuvre des utilitaires qui y sont impliqués. <sect1 id="paquetssources-1-1"><tt>dpkg-source</> - création et extraction des paquets sources Debian Ce programme est fréquemment utilisé sur la ligne de commande, et est aussi appelé à partir des scripts de construction automatique de paquet indépendant, tel que <prgn/dpkg-buildpackage/. Pour extraire un paquet, on utilise: <example> dpkg-source -x ../chemin/du/fichier</>.dsc </example> Avec le fichier <tt>.tar.gz</> et le fichier <tt>.diff.gz</> (si c'est utile) dans le même répertoire. Il extrait un paquet package-version</> et s'il est présent un paquet package-version</><tt>.orig</> dans le même répertoire. Pour créer une paquet, on utilise: <example> dpkg-source -b package-version</> </example> Ceci créera les fichiers <tt>.dsc</>, <tt>.tar.gz</> et <tt>.diff.gz</> (si c'est utile) dans le répertoire courant. <prgn/dpkg-source/ n'efface pas l'arborescence des sources. Ceci doit être fait séparément, si nécessaire. Voir aussi <ref id="paquetssources-3">. <sect1 id="paquetssources-1-2"><tt>dpkg-buildpackage</> - script général de contrôle de construction de paquet <prgn/dpkg-buidpackage/ est un script qui fait appel à <prgn/dpkg-source/ avec les règles du fichier <tt>debian/rules</> : <tt>clean</>, <tt>build</>, et <tt>binary</> et les programmes <prgn/dpkg-genchanges/ et <prgn/pgp/ pour construire une distribution signée de paquets source et binaire. Il est généralement utilisé sur la ligne de commande, à la racine du répertoire source à créer ou à détruire. Il peut être invoqué sans arguments. Les arguments utiles sont: <taglist> <tag> -uc, -us <item> Signifie, ne pas crypter, avec PGP, respectivement le fichier <tt>.change</> et le fichier paquet source <tt>.dsc</>. <tag> -ppgp-command <item> Invoque la commande pgp-command</> au lieu de chercher <prgn/pgp/ dans la variable <tt>PATH</>. pgp-command</> doit avoir le même comportement que <prgn/pgp/. <tag> -rroot-command <item> Quand les privilèges de root sont nécessaires, invoque la commande root-command</>. root-command</> doit invoquer son premier argument comme une commande, dans le <tt>PATH</> si nécessaire, et passer son second argument et les autres à la commande appelée. Si aucune root-command</> n'est fournie alors <prgn/dpkg-buildpackage/ ne fera aucune action pour obtenir les privilèges root, afin que pour démarrer la plupart des paquets root soit nécessaire. <tag> -b, -B <item>Deux types de binaire: construit et charger, voir <manref name="dpkg-source" section="1">). </taglist> <sect1 id="paquetssources-1-3"><tt>dpkg-gencontrol</> - génère les fichiers de contrôle des paquets binaires Ce programme est habituellement appelé à partir du fichier <tt>debian/rules</> (voir <ref id="paquetssources-2">) depuis la racine de l'arborescence source. Ceci est généralement fait juste avant que les fichiers et les répertoires, dans le répertoire temporaire où le paquet est en train de se construire, ont établi leurs permissions et leurs propriétaires et avant la construction du paquet par <prgn/dpkg-deb/ <footnote>Il en est ainsi afin que le fichier de contrôle produit possède les bonnes permissions</footnote>. <tt>dpkg-gencontrol</> doit être appelé après que tous les fichiers du paquet aient été mis en place dans le répertoire temporaire de construction, afin que le calcul de la taille du paquet installé soit correct. Il est aussi nécessaire pour <prgn/dpkg-gencontrol/ d'être exécuté après <prgn/dpkg-shlibdeps/ afin que les variables de substitutions, créées par <prgn/dpkg-shlibdeps/ dans le fichier <tt>debian/substvars</>, soient disponibles. Pour un paquet qui génère seulement un paquet binaire, et qui est construit dans le répertoire <tt>debian/tmp</> par rapport à la racine du paquet source, il suffit d'appeler: <example> dpkg-gencontrol </example> Les sources qui construisent plusieurs binaires utiliseront: <example> dpkg-gencontrol -Pdebian/tmp-pkg</> -ppackage</> </example> L'argument <tt>P</> indique à <prgn/dpkg-gencontrol/ que le paquet est en train de se construire dans un répertoire différent que celui par défaut et <tt>-p</> indique quel fichier de contrôle de paquet doit être généré. <prgn/dpkg-gencontrol/ ajoute aussi des informations à la liste des fichiers du répertoire <tt>debian/file</> pour un futur appel à <tt>dpkg-genchanges</>. <sect1 id="paquetssources-1-4"><tt>dpkg-shlibdeps</> - calcule les dépendances des librairies partagées Ce programme est habituellement appelé à partir du fichier <tt>debian/rules</>, juste avant <prgn/dpkg-gencontrol/ (voir <ref id="paquetssources-2">), à la racine de l'arborescence source. Les arguments sont des exécutables <footnote>Il en est ainsi afin que le fichier de contrôle produit possède les bonnes permissions</footnote>  <footnote>Ils peuvent être spécifiés soit dans les emplacements de l'arborescence source où ils sont crées ou soit dans les emplacements dans l'arbre de construction temporaire où ils sont installés avant la création du paquet binaire.</footnote> pour lesquels les dépendances des librairies partagées devraient être incluses dans le fichier de contrôle de paquet. Si certains exécutables librairies partagées doivent seulement justifier d'un <tt>Recommends</> ou d'un <tt>Suggests</>, ou si certains demandent un <tt>Pre-Depends</>, ceci peut être réaliser en utilisant l'option <tt>-d</>dependency-field</> avant ces exécutables (chaque option <tt>-d</> prends effet jusqu'au prochain <tt>-d</>). <prgn/dpkg-shlibdeps/ ne modifie pas directement le fichier de contrôle. Par défaut, il ajoute au fichier <tt>debian/substvars</> des variables comme <tt>shlibs:Depends</>. Ces variables doivent être référencées dans le champ dépendance dans la section appropriée des paquets binaires du fichier de contrôle source. Par exemple, le paquet <prgn/procps/ génère deux types de binaires, des binaires simples comme <prgn/ps/ qui requièrent une pré-dépendance, et des binaires utilisant <prgn/ncurses/ comme <prgn/top/ qui nécessitent seulement une recommandation. Cela peut être indiqué dans le fichier <tt>debian/rules</> par: <example> dpkg-shlibdeps -dPre-Depends ps -dRecommends top </example> Et ensuite dans le fichier principal de contrôle <tt>debian/control</>: <example> ... Package: procps Pre-Depends: ${shlibs:Pre-Depends} Recommends: ${shlibs:Recommends} ... </example> Les sources qui produisent plusieurs paquets binaires avec des exigences différentes de dépendance de librairie partagée peuvent utiliser l'option <tt>-p</>varnameprefix</> pour écraser le préfixe <tt>shlib:</> par défaut (un appel à <prgn/dpkg-shlibdeps/ par réglage de cette option). Elles peuvent ainsi produire plusieurs ensembles de variables de dépendance, chacune de la forme varnameprefix:dependencyfield</>, qui peuvent être référencées dans les parties appropriées des fichiers de contrôle des paquets binaires. <sect1 id="paquetssources-1-5"><tt>dpkg-distaddfile</> - ajoute un fichier à <tt>debian/files</> Certains chargements de paquets nécessitent d'inclure des fichiers en plus des fichiers des paquets sources et binaires. <prgn/dpkg-distaddfile/ ajoute une ligne au fichier <tt>debian/files</> afin qu'il soit inclus dans le fichier <tt>.changes</> lorsque <prgn/dpkg-genchanges/ sera lancé. Il est habituellement invoqué à partir de la cible <tt>binary</> du fichier <tt>debian/rules</>: <example> dpkg-distaddfile filename section priority</> </example> L'argument nom du fichier filename</> est relatif au répertoire où <prgn/dpkg-genchanges/ s'attend à le trouver, généralement au dessus de la racine de l'arborescence source. La règle de <tt>debian/rules</> devrait placer ce fichier juste avant ou juste après l'appel à <prgn/dpkg-distaddfile/. Les arguments section</> et priority</> sont placés sans modification dans le fichier résultat <tt>.changes</>. Voir <ref id="fichierscontroles-2-9">. <sect1 id="paquetssources-1-6"><tt>dpkg-genchanges</> - génère un fichier de contrôle de chargement <tt>.changes</> Ce programme est généralement appelé par des scripts de construction automatique de paquet indépendant tels que <prgn/dpkg-buildpackage/ mais peut être aussi appelé sur la ligne de commande. Il est habituellement exécuté à la racine du répertoire de l'arbre source construit, et quand il est invoqué sans arguments, il écrira directement un fichier <tt>.changes</> basé sur les informations des fichiers de contrôle et de changement des paquets sources, et des paquets sources et binaires qui ont dû être construit. <sect1 id="paquetssources-1-7"><tt>dpkg-parsechangelog</> - produit une représentation analysée d'un fichier changelog</> Ce programme est utilisé en interne par <prgn/dpkg-source/ et autres. Il peut être aussi occasionnellement utilisé dans <tt>debian/rules</> et autre part. Il analyse un fichier changelog</>, par défaut <tt>debian/changelog</>, et affiche sur la sortie standard une représentation formatée de fichier de contrôle des informations contenues. <sect id="paquetssources-2">L'arbre source débianisé La structure de l'archive source, décrit ci-dessous, a été conçu pour permettre à un arbre source débianisé, avec les informations de contrôle associées, d'être dupliqué et facilement transporté. L'arbre source débianisé est une version du programme original avec certains fichiers ajoutés pour le processus de débianisation, ainsi que n'importe quels changements nécessaires réalisés sur les codes sources et scripts d'installation. Les fichiers supplémentaires crées pour la Debian sont dans le répertoire <tt>debian</> à la racine de l'arbre source débianisé. Ils sont décrits ci-dessous. <sect1 id="paquetssources-2-1"><tt>debian/rule</> - le script principal de construction Ce fichier est un makefile</> exécutable, qui contient les règles spécifiques au paquet pour compiler et construire les binaires des paquets sources. Il doit commencer par une ligne: <example> #!/usr/bin/make -f </example> afin de pouvoir être appelé directement sans faire <prgn/make/. Les règles nécessaires sont: <taglist> <tag> build <item> Configuration non interactive et compilation du paquet. Si un paquet a une routine de configuration préalable interactive, alors le paquet source débianisé devra être construit après cette opération afin qu'il puisse fonctionner sans réexécuter cette configuration. Pour certains paquets, notamment ceux où le même arbre source est compilé de différentes façons pour obtenir deux paquets binaires, la règle <tt>build</> n'a aucun sens. Pour ces paquets, il est bon de prévoir deux règles ou plus (<tt>build-a</> et <tt>build-b</> ou autre) pour chaque manière de construire le paquet et une règle <tt>build</> qui ne produit rien. La règle <tt>binary</> s'occupera de construire le paquet pour chaque cas possible et de créer le paquet binaire de chacun d'eux. La règle <tt>build</> ne doit pas effectuer d'actions qui exigent les privilèges de root. La règle <tt>build</> peut avoir besoin d'exécuter d'abord la règle <tt>clean</>. Voir ci-dessous. Quand un paquet possède une routine de configuration qui prend du temps, ou quand le makefile</> est pauvrement conçu, ou quand <tt>build</> a besoin d'exécuter <tt>clean</> d'abord, il est alors intéressant d'exécuter <prgn/touch build/ quand le processus <tt>build</> est terminé. Cela assurera que si <tt>build</> de <tt>debian/rules</> est exécuté à nouveau, il ne reconstruira pas le programme complet. <tag> binary, binary-arch, binary-indep <item> La règle <tt>binary</> devrait être tout ce qui est nécessaire pour l'utilisateur pour construire le paquet binaire. Elle est découpée en deux parties: <tt>binary-arch</> construit les fichiers de sortie des paquets qui sont spécifiques à une architecture particulière, et <tt>binary-indep</> construit les fichiers que ne le sont pas. <tt>binary</> devrait être généralement une règle, avec aucune commande, qui dépend simplement de <tt>binary-arch</> et <tt>binary-indep</>. Les deux règles de <tt>binary</> (<tt>binary-arch</> et <tt>binary-indep</>) devrait dépendre de la règle <tt>build</>, ci-dessus, afin que le paquet soit construit si ce n'est pas déjà le cas. Il doit ensuite créer les paquets binaires pertinents en utilisant <prgn/dpkg-gencontrol/ pour créer leurs fichiers de contrôle et <prgn/dpkg-build/ pour les binaires, et les placer le répertoire parent du répertoire racine. Si une des deux règles n'a pas de commandes (ce sera toujours le cas, si le source génère seulement un paquet binaire dépendant de l'architecture ou non), elle doit tout de même exister. <ref id="paquetsbinaires"> décrivent comment construire les paquets binaires. La règle <tt>binary</> doit être invoquée avec le privilège root. <tag> clean <item> Procède au nettoyage des effets obtenus par les règles <tt>build</> et <tt>binary</>, sauf pour les fichiers de sortie du répertoire parent crées par la règle <tt>binary</>. Si le fichier <tt>build</> est mis à jour par <prgn/touch/ à la fin de la règle <tt>build</>, comme suggéré ci-dessus, c'est la première chose qui doit être effacée par la règle <tt>clean</>, afin que si on exécute de nouveau <tt>build</> après une interruption, <tt>clean</> ne pense pas que tout est déjà fait. La règle <tt>clean</> doit être invoquée sous root, si <tt>binary</> a été invoqué depuis le dernier <tt>clean</>, ou si <tt>build</> a été invoqué sous root (étant donné que <tt>build</> peu créer des répertoires par exemple). <tag> get-orig-source (optionnel) <item> Cette règle va chercher la version la plus récente du paquet original à partir d'un site d'archive autorisé (par FTP ou WWW, par exemple), s'occupe des réarrangements nécessaires pour le rendre dans un format de fichier archive source original décrit ci-dessus, et le laisse dans le répertoire courant. Cette règle peut être invoquée dans n'importe quelle répertoire et doit s'occuper de nettoyer ses fichiers temporaires. Elle est optionnelle, mais la fournir, si c'est possible, est une bonne idée. </taglist> Les règles <tt>build</>, <tt>binary</> et <tt>clean</> doivent être invoquées dans le répertoire courant du répertoire racine du paquet. Des règles supplémentaires peuvent exister dans <tt>debian/rules</>, soit comme des interfaces publiées ou non documentées ou pour l'utilisation interne du paquet. <sect1 id="paquetssources-2-2"><tt>debian/control</> Ce fichier contient les détails indépendants des versions des paquets sources et des paquets binaires qu'il crée. C'est une série d'ensemble de champ de contrôle, chacun syntaxiquement similaire à un fichier de contrôle de paquet binaire. Les ensembles sont séparés par une ou plusieurs lignes vides. Le premier ensemble contient en général les informations sur le paquet source; chaque ensemble suivant décrit un paquet binaire que l'arbre source construit. la syntaxe et la sémantique des champs sont décrites ci-dessous dans <ref id="fichierscontroles">. Les champs généraux (indépendant des paquets binaires) sont: <taglist> <tag> Source <item> Obligatoire <tag> Maintainer <item> <tag> Section and Priority <item> (classification, obligatoire) <tag> Standards-Version <item> </taglist> Les champs pour les paquets binaires sont: <taglist> <tag> Package <item> Obligatoire <tag> Architecture <item> Obligatoire <tag> Description <item> <tag> Section and Priority <item> (classification) <tag> Essential <item> <tag> Depends et autres <item> (relations entres paquets) </taglist> Ces champs sont utilisés par <prgn/dpkg-gencontrol/ pour générer les fichiers de contrôle pour les paquets binaires (voir ci-dessus), par <prgn/dpkg-genchanges/ pour générer le fichier <tt>.changes</> qui accompagne le chargement et par <prgn/dpkg-source/ quand il crée le fichier de contrôle source <tt>.dsc</> comme une partie de l'archive source. Les champs peuvent contenir des références aux variables, leurs valeurs seront substituées par <prgn/dpkg-gencontrol/, <prgn/dpkg-genchanges/ ou <prgn/dpkg-source/ quand ils génèrent leurs fichiers de sortie. Voir <ref id="paquetssources-2-3"> pour détails. <sect2 id= "paquetssources-2-2-1">Les champs définis par l'utilisateur Des champs utilisateurs supplémentaires peuvent être ajoutés au fichier de contrôle du paquet source. Ces champs seront ignorés, ne seront pas copiés dans les fichiers de contrôle des paquets sources ou binaires (par exemple) ou dans les fichiers de contrôle de chargement. Si tu souhaites ajouter des champs supplémentaires non supportés à ces fichiers de sortie, tu dois utiliser le mécanisme décrit ci-dessous. Les champs du fichier principal d'information de contrôle de source avec des noms commençant par X, suivis par une ou plusieurs lettres <tt>BCS</> et un tiret -, seront copiés vers les fichiers de sortie. Seule la partie du nom du champ qui se trouve après le tiret sera utilisée dans le fichier de sortie. Si la lettre B est utilisée, le champ apparaîtra dans les fichiers de contrôle des paquets binaires, si c'est la lettre S, dans les fichiers de contrôle de paquet source, et si c'est la lettre C, dans les fichiers de contrôle de chargement (<tt>.changes</>). Par exemple, le fichier principal d'information de contrôle source contient le champ suivant: <example> XBS-Comment: I stand between the candle and the star. </example> alors les fichiers de contrôle des paquets sources et binaires contiendront le champ: <example> Comment: I stand between the candle and the star. </example> <sect2 id= "paquetssources-2-2-2"><tt>debian/changelog</> Ce fichier enregistre les changements des parties spécifiques Debian d'un paquet <footnote>Bien qu'il n'y ait rien qui empêche un auteur qui est aussi le mainteneur Debian de l'utiliser pour tous les changements, il devra être renommé si les mainteneurs originaux et Debian deviennent physiquement différents.</footnote>. Il a un format spécial qui permet aux outils de construction de paquets de découvrir quelle version du paquet est en train de se construire et de trouver d'autres informations spécifiques à la version. Le format est une série d'entrée comme ça: <example> package</> (version</>) distributions(s)</>; <tt>urgency=</>urgency</> * détails des modifications plus de détails * encore plus de détails -- nom du mainteneur et adresse email date </example> package</> et version</> sont le nom du paquet source et le numéro de version. distribution(s)</> listent les distributions où cette version devrait être installée quand elle est chargée. C'est copié du champ <tt>Distributions</> dans le fichier <tt>.changes</>. Voir <ref id="fichierscontroles-2-14">. urgency</> est la valeur pour le champ <tt>Urgency</> dans le fichier <tt>.changes</> pour le chargement. Voir <ref id="fichierscontroles-2-15">. Il n'est pas possible de spécifier une urgency</> contenant des virgules; les virgules sont utilisées pour séparer les couples (mot clé=valeur) dans le format du fichier d'enregistrement de <tt>dpkg</> (bien qu'il n'y ait pour l'instant seulement un mot clé utile: <tt>urgency</>). Les détails des modifications peuvent être, en fait, n'importe quelles séries de ligne commençant au moins par deux espaces, mais par convention, chaque modification commence par une étoile * et un espace, les lignes de continuation sont indentées pour les amener en face du texte de la ligne précédente. Les lignes vides peuvent être utilisées pour séparer les groupes de modifications, si désiré. Le nom du mainteneur et son adresse email ne sont pas nécessairement les mêmes que ceux du mainteneur habituel du paquet. Ils doivent correspondre à la personne qui s'est occupée ce cette version. Les informations seront copiées dans le fichiers <tt>.changes</>, et plus tard, utilisées pour envoyer un acquittement quand le chargement sera installé. La date doit être dans le format RFC822 <footnote>générée par le programme <prgn/822-date/</footnote>; elle doit inclure le nom du fuseau horaire (timezone) spécifié numériquement, et en option le nom du fuseau ou son abréviation. La première ligne 'titre' avec le nom du paquet doit commencer sur la marge de gauche, la ligne de 'fin' avec les détails sur le mainteneur et la date, doit être précédée par exactement un espace. Les détails du mainteneur et la date doivent être séparés exactement par deux espaces. Un mode Emacs pour éditer ce format est disponible: <tt>debian-changelog-mode</>. Tu peux sélectionner ce mode automatiquement quand tu édites un fichier <tt>changelog</> Debian en ajoutant une clause de variables locales à la fin du fichier <prgn/changelog/. <sect2 id= "paquetssources-2-2-3">Définition de formats alternatifs pour le fichier <tt>changelog</> Il est possible d'utiliser un format différent de celui proposé, en fournissant un analyseur avec le format que tu veux utiliser. De façon à ce que <prgn/dpkg-parsechangelog/ exécute ton parseur (analyseur), tu dois inclure une ligne à l'intérieur des 40 dernières lignes de ton fichier s'apparentant à l'expression régulière Perl: <example> \schangelog-format:\s+([0-9a-z)+\W </example> La partie entre parenthèses doit être le nom du format, par exemple: <example> @@@ changelog-format: joebloggs @@@ </example> Les noms de format de fichier <prgn/changelog/ sont des chaînes alphanumériques non vides. Si une telle ligne existe, alors <prgn/dpkg-parsechangelog/ cherchera l'analyseur dans: <example> /usr/lib/dpkg/parsechangelog/nom-format ou /usr/local/lib/dpkg/parsechangelog/nom-format </example> Une erreur est renvoyée si le fichier n'est pas trouvé ou s'il n'est pas exécutable. Le format <prgn/changelog/ par défaut est <tt>dpkg</> et un analyseur est fourni avec le paquet <tt>dpkg</>. L'analyseur sera invoqué avec le fichier <prgn/changelog/ ouvert sur l'entrée standard au début. Il doit lire le fichier (ou le parcourir avec seek) pour trouver l'information et retourner cette information analysée sur la sortie standard sous la forme d'une série de champ de contrôle dans le format standard. Par défaut, il devrait retourner seulement les informations les plus récentes du fichier <prgn/changelog/; il doit accepter l'option <tt>-v</>version</> pour retourner les informations de changement de toutes les versions présentes strictement supérieures version</> et rendre une erreur pour une version non présente dans le fichier <prgn/changelog/. Les champs sont: <taglist> <tag> Source <item> <tag> Version <item> Obligatoire <tag> Distributions <item>Obligatoire <tag> Urgency <item>Obligatoire <tag> Maintener <item>Obligatoire <tag> Date <item> <tag> Changes <item>Obligatoire </taglist> Si plusieurs versions sont retournées (à cause de l'utilisation de l'option <tt>-v</>), la valeur <tt>urgency</> doit être la plus grande listée au début de n'importe quelle version requise suivie par les commentaires concaténés (séparés par un espace) de toutes les versions requises, les champs: le mainteneur, la version, la distribution et la date proviennent toujours de la version la plus récente . Pour le format du champ <tt>Changes</> voir <ref id="fichierscontroles-2-18">. Si le format du fichier <tt>changelog</> qui est en train d'être analysé, laisse toujours ou presque toujours une ligne vide entre les notes de modifications individuelles, ces lignes vides peuvent être supprimées, pour rendre le résultat de sortie plus compact. Si le format de <prgn/changelog/ ne contient pas de date ou d'information sur le nom du paquet, ces informations doivent être omises en sortie. L'analyseur ne doit pas essayer de les synthétiser ou de les trouver à partir d'autres sources. Si le fichier <prgn/changelog/ n'a pas le format attendu, l'analyseur doit se terminer avec un statut différent de zéro, plutôt que d'essayer de se débrouiller tant bien que mal et générer des sorties incorrectes. L'analyseur du fichier <prgn/changelog/ ne doit pas du tout interagir avec l'utilisateur. <sect1 id="paquetssources-2-3"><tt>debian/substvars</> et substitutions de variables Quand <prgn/dpkg-gencontrol/, <prgn/dpkg-genchanges/ et <prgn/dpkg-source/ génèrent des fichiers de contrôle, ils font de la substitution de variable sur leurs sorties juste avant de les écrire. Les substitutions de variable ont la forme <tt>${</>nom-variable</><tt>}</>. Le fichier optionnel <tt>debian/substvars</> contient les substitutions de variable à utiliser. Les variables peuvent être aussi positionnées directement à partir de <tt>debian/rules</> en utilisant l'option <tt>-v</> par les commandes de paquetage source et certaines variables prédéfinies sont disponibles. Ceci est habituellement généré et modifié dynamiquement par les règles de <tt>debian/rules</>, dans ce cas, il doit être enlevé par la règle <tt>clean</>. Voir <manref name="dpkg-source" section="1"> pour plus de détails sur les substitutions de variables source, incluant aussi le format de <tt>debian/substvars</>. <sect1 id="paquetssources-2-4"><tt>debian/files</> Ce fichier n'est pas un fichier permanent de l'arbre source, il est utilisé pendant la construction des paquets pour enregistrer quels fichiers sont en train d'être générés. <prgn/dpkg-genchanges/ l'utilise quand il génère un fichier <tt>.changes</>. Ce fichier ne doit pas exister dans un paquet source expédié, et il doit être effacé par la règle <tt>clean</> (ainsi que n'importe quels fichiers de sauvegarde ou temporaire tel que <tt>files.new</> <footnote><tt>file.news</> est utilisé temporairement par <prgn/dpkg-gencontrol/ et <prgn/dpkg-distaddfile/, ils écrivent une nouvelle version de <tt>files</> avant de le renommer, pour éviter de laisser une copie corrompue, si une erreur se produit.</footnote>). Il peut aussi être sage, pour assurer un nouveau départ, de l'enlever ou de le vider au début de la règle <tt>binary</>. <prgn/dpkg-gencontrol/ ajoute une entrée à ce fichier, pour le fichier <tt>.deb</> qui sera crée par <prgn/dpkg-deb/ à partir du fichier de contrôle qu'il génère, ainsi pour la plupart des paquets, il n'y a qu'à effacer ce fichier dans la règle <tt>clean</>. Si un chargement de paquet inclut des fichiers à côté des paquets sources et binaires dont les fichiers de contrôle ont été crée par <prgn/dpkg-gencontrol/, alors ils doivent être placés dans le répertoire parent du répertoire racine du paquet et <prgn/dpkg-distaddfile/ doit être appelé pour ajouter ces fichiers à la liste <tt>debian/files</>. <sect1 id="paquetssources-2-5"><tt>debian/tmp</> C'est l'emplacement temporaire, pour la construction des paquets binaires pour la règle <tt>binary</>. Le répertoire <tt>tmp</> sert de racine à l'arbre du système de fichier qui est en train de se construire (par exemple en utilisant la règle d'installation du <prgn/Makefile/ du paquet original et en le redirigeant dans <tt>tmp</>), et il contient aussi le sous-répertoire <tt>DEBIAN</>. Voir <ref id="paquetsbinaires-1">. Si plusieurs paquets binaires sont générés à partir du même arbre source, il est habituel d'utiliser plusieurs répertoires <tt>debian/tmp-truc</>, par exemple <tt>tmp-a</> ou <tt>tmp-doc</>. Quelque soit les répertoires <tt>tmp</> crées et utilisés par <tt>binary</>, la règle <tt>clean</> doit bien sûr les effacer. <sect id="paquetssources-3">Les paquets sources comme archives Sur les sites FTP, les paquets sources contiennent trois fichiers qui ont des liens. Tu dois avoir les bonnes versions pour les trois pour pouvoir les utiliser. <taglist> <tag> fichier de contrôle source Debian - <tt>.dsc</> <item> Ce fichier contient une série de champs, identifiés et séparés comme les champs dans le fichier de contrôle d'un paquet binaire. Les champs sont listés ci-dessous; leur syntaxe est décrite ci-dessus dans <ref id="fichierscontroles">. <taglist compact> <tag> Source <item> <tag> Version <item> <tag> Maintener <item> <tag> Binary <item> <tag> Architecture <item> <tag> Standards-Version <item> <tag> Files <item> </taglist> Le fichier de contrôle du paquet source est généré par <prgn/dpkg-source/ quand il crée l'archive source, à partir des autres fichiers dans le paquet source, décrit ci-dessus. Quand on le déballe, il est vérifié par rapport aux autres fichiers et répertoires dans les autres parties du paquet source, comme décrit ci-dessous. <tag> archive du source original - paquet-version-originale</><tt>.orig.tar.gz</> <item> C'est un fichier <prgn/tar/ compressé (avec <prgn/gzip -9/) contenant le code source de l'auteur original du programme. Le fichier <prgn/tar/ est déballé dans un répertoire paquet-version- originale</><tt>.orig</>. Il ne contient aucun fichier en dehors de ses sous-répertoires. <tag> fichier <tt>diff</> de Débianisation - paquet-révision-version-originale</><tt>.diff.gz</> <item> C'est un fichier <tt>diff</> unifié (<prgn/diff -u/) donnant les changements requis pour modifier le source original en source Debian. Ces changements peuvent inclure seulement une édition ou une création de fichier tout bonnement. Les permissions des fichiers, les cibles des liens symboliques et les caractéristiques des fichiers spéciaux ou "pipes" ne peuvent pas être changés et aucun fichier ne doit être enlevé ou renommé. Tous les répertoires dans le fichier <tt>diff</> doivent exister, sauf le sous-répertoire <tt>debian</> à la racine de l'arbre source, qui sera crée par <prgn/dpkg-source/, si nécessaire, lors de l'extraction. Le programme <prgn/dpkg-source/ rendra automatiquement exécutable le fichier <tt>debian/rules</> (voir ci-dessous). </taglist> S'il n'y a pas de code source original, par exemple, si le paquet a été spécialement préparé pour la Debian ou si le mainteneur Debian est le même que le mainteneur original, le format est alors légèrement différent: il n'y pas de fichier <tt>diff</> et le fichier <prgn/tar/ est nommé paquet-version</><tt>.tar.gz</> et contient un répertoire paquet-version</>. <sect id="paquetssources-4">Extraire un paquet source Debian sans <prgn/dpkg-source/ <prgn/dpkg-source -x/ est la manière recommandée pour extraire un paquet source Debian. Cependant, si le programme n'est pas disponible, il est possible d'extraire une archive source Debian comme suit: <enumlist> <item>Détarer le fichier <prgn/tar/, pour créer un répertoire <tt>.orig</>. <item>Renommer le répertoire <tt>.orig</> en paquet-version</>. <item>Créer le sous-répertoire Debian à la racine de l'arbre source. <item>Appliquer le fichier <tt>diff</> en utilisant <prgn/patch -p0/. <item>Détarer le fichier <prgn/tar/ de nouveau, si tu veux une copie du code source original à côté de la version débianisée. </enumlist> Il n'est pas possible de générer une archive source Debian valide sans utiliser <prgn/dpkg-source/. En particulier, essayer d'utiliser <prgn/diff/ directement pour générer le fichier <tt>.diff.gz</> ne fonctionnera pas. <sect1 id="paquetssources-4-1">Restrictions sur les objets dans les paquets sources Le paquet source ne doit contenir de lien "hard" <footnote>Ce n'est pas détecté pendant la construction des paquets sources, mais seulement pendant leurs extractions.</footnote> <footnote>Les liens "hard" pourront être autorisés dans le futur à certain point, mais demande beaucoup plus de travail.</footnote> , de fichiers spéciaux de périphériques, de sockets ou de fichiers "setuid" ou "setgid" <footnote>Les répertoires "setgid" sont autorisés</footnote>. Les outils de paquetage source gèrent les modifications entre les fichiers sources originaux et ceux débianisés en utilisant <prgn/diff/ et <prgn/patch/. Modifier l'arbre source original inclus dans <tt>.orig.tar.gz</> en un source débianisé ne doit pas impliquer de changements qui ne peuvent pas être maintenus par ces outils. Les changements problématiques qui provoquent une erreur de la part de <prgn/dpkg-source/ pour construire le paquet source sont: <list compact> <item>Ajouter ou enlever des liens symboliques, des sockets ou des "pipes", <item>Changer les cibles des liens symboliques, <item>Créer des répertoires autre que <tt>debian</>, <item>Changer le contenu des fichiers binaires. </list> Les modifications qui afficheront un avertissement de la part de <prgn/dpkg-source/ sont: <list compact> <item>Enlever des fichiers, des répertoires ou des liens <footnote>Renommer un fichier n'est pas traité spécialement. C'est vue comme l'effacement d'un vieux fichiers (qui génère un avertissement, mais il est ignoré autrement) et la création d'un nouveau.</footnote>, <item>Les fichiers textes modifiés où ils manquent le retour chariot final (aussi bien dans l'arbre source original que celui modifié). </list> Les changements qui ne sont pas représentés, et qui ne sont pas détectés par <prgn/dpkg-source/ sont: <list compact> <item>Changer les permissions des fichiers (autres que <tt>debian/rules</>) et des répertoires. </list> Le répertoire Debian <tt>debian/rules</> est manipulé spécialement par <prgn/dpkg-source/. Avant d'appliquer les changements, il créera le répertoire <tt>debian</>, après quoi il rendra exécutable le fichier <tt>debian/rules</>. *********************************************************************** <chapt id="fichierscontroles">Les fichiers de contrôle et leurs champs Beaucoup d'outils dans la suite <tt>dpkg</> manipulent les données dans un format commun, connu sous le nom de fichiers de contrôle. Les paquets source et binaire ont des données de contrôle comme les fichiers <tt>.changes</> qui contrôlent l'installation et le chargement des fichiers, et les bases de données internes à <tt>dpkg</> sont dans un format similaire. <sect id="fichierscontroles-1">La syntaxe des fichiers de contrôle Un fichier consiste en un ou plusieurs paragraphes de champs. Ces paragraphes sont séparés par des lignes blanches. certains fichiers de contrôle n'autorisent qu'un seul paragraphe; d'autres plusieurs, dans ce cas, chaque paragraphe fait souvent référence à différent paquet. Chaque paragraphe est une série de champs et de valeurs; chaque champ est constitué d'un nom, suivi par deux-points et la valeur. Il se termine à la fin de la ligne. Les espaces horizontaux (espaces et tabulations) peuvent apparaître avant ou après la valeur et sont ignorés; par convention, il y a un espace après les deux-points. Certaines valeurs de champs peuvent s'étaler sur plusieurs lignes; dans ce cas, chaque continuation de ligne doit commencer par un espace ou une tabulation. N'importe quels espaces ou tabulations à la fin des lignes d'un champ de valeur est ignoré. Sauf où cela est indiqué, seulement une simple ligne de données est autorisée et les espaces ne sont pas significatifs dans un corps de champ. Les espaces ne doivent jamais apparaître dans les noms (de paquets, d'architectures, de fichiers, etc), dans les numéros de version ou entre les caractères des relations de version. Les lignes vides ou les lignes contenant seulement des espaces ou des tabulations ne sont pas autorisées à l'intérieur des champs de valeur ou entre les champs - ce qui marqueraient un nouveau paragraphe. Il est important de noter qu'il y a plusieurs champs qui sont optionnels tant que <tt>dpkg</> et les outils associés sont concernés, mais qui doivent apparaître dans chaque paquet Debian, ou dont l'omission peut entraîner des problèmes. Quand tu écrits des fichiers de contrôle pour les paquets Debian, tu dois lire le manuel des principes Debian en même temps que les détails ci-dessous et la liste des champs pour un fichier particulier. <sect id="fichierscontroles-2">La liste des champs <sect1 id="fichierscontroles-2-1"><tt>Package</> Le nom du paquet binaire. Les noms de paquet sont constitués de caractères alphanumériques et <tt>+ - .</> (plus, moins, point). <footnote>Les caractères <tt>@ : = % _</> (at, deux-point, égal, pourcent, underscore) étaient autorisés et sont toujours acceptés quand ils sont trouvés dans un fichier de paquet, mais ne doivent pas être utilisés dans les nouveaux paquets.</footnote> Ils doivent contenir au moins deux caractères et commencer par un caractère alphanumérique. Dans la version courante de dpkg, ils sont triés par ordre alphabétique en tenant compte des majuscules <footnote>C'est une erreur</footnote>; utilise des noms de paquets en minuscule à moins que le paquet que tu construis (ou est référencé dans d'autres champs) utilise déjà des majuscules. <sect1 id="fichierscontroles-2-2"><tt>Version</> Ce champ liste le numéro de version des paquets source ou binaire - voir <ref id="numeroversions">. <sect1 id="fichierscontroles-2-3"><tt>Architecture</> Ce champ est une chaîne de caractères correspondant à une architecture; c'est un simple mot pour l'architecture. <tt>dpkg</> vérifiera l'architecture déclarée d'un paquet binaire avec sa propre valeur in situ avant de l'installer. La valeur spéciale <tt>all</> indique que le paquet est indépendant de l'architecture. Dans le fichier principal <tt>debian/control</> du paquet source, ou dans le fichier de contrôle des paquets sources <tt>.dsc</>, une liste des architectures (séparée par des espaces) est aussi autorisée, tout comme la valeur spéciale <tt>any</t>. Une liste indique que le source construira un paquet dépendant de l'architecture, et fonctionnera correctement seulement sur les architectures listées. <tt>any</> indique que même si le paquet source n'est pas dépendant d'une architecture particulière et devrait bien se compiler sur n'importe laquelle, les paquets binaires produits ne sont pas indépendants des architectures mais sera par contre spécifique à l'architecture courante de construction. Dans un fichier <tt>.changes</>, le champ <tt>Architecture</> liste la ou les architectures des paquets qui sont chargés. Ce sera une liste; si le source du paquet est aussi chargé, l'entrée spéciale <tt>source</> est aussi présent. L'architecture courante de construction peut être déterminée en utilisant <tt>dpkg --print-architecture</><footnote>Qui appelle: <tt>gcc --print-libgcc-file-name</> et analyse et décompose la sortie et cherche le type de CPU à partir de la configuration de GCC dans une table de <tt>dpkg</>. C'est ainsi afin de fonctionner si tu fais de la cross- compilation.</footnote>. Cette valeur est automatiquement utilisée par <tt>dpkg-gencontrol</> quand il construit le fichier de contrôle pour un paquet binaire pour lequel les informations de contrôle source ne spécifient pas l'architecture <tt>all</>. Il existe une option à part, <tt>--print-installation-architecture</>, pour trouver quelle architecture, <tt>dpkg</> est prêt à installer. Cette information est aussi dans la sortie de <tt>dpkg --version</>. <sect1 id="fichierscontroles-2-4"><tt>Maintener</> Ce champ contient le nom du mainteneur et son adresse de courrier électronique. Le nom vient d'abord, suivi par l'adresse du courrier électronique entre les signes inférieurs et supérieurs <tt><></t> (au format RFC822). Si le nom du mainteneur contient un point alors le champ entier ne fonctionnera pas directement comme une adresse électronique à cause d'un problème dans la syntaxe spécifiée dans la RFC822; un programme utilisant ce champ comme une adresse doit vérifier cela et corriger le problème si nécessaire (par exemple en mettant entre parenthèses le nom et en le déplaçant à la fin, et en amenant l'adresse électronique devant). Le fichier <tt>.changes</> ou les données analysées de changelog contiennent le nom et l'adresse électronique de la personne responsable de cette version particulière en question - ce n'est pas forcément le mainteneur habituel du paquet. Ce champ est habituellement optionnel tant qu'il concerne <tt>dpkg</>, mais son absence génère généralement un avertissement lors de la construction de paquets. <sect1 id="fichierscontroles-2-5"><tt>Source</> Ce champ identifie le nom du paquet source. Dans un fichier principal d'information de contrôle de source ou dans un fichier <tt>.changes</> ou dans un fichier <tt>.dsc</> ou dans les données analysées de changelog, ceci peut seulement contenir le nom du paquet source. Dans un fichier de contrôle d'un paquet binaire (ou dans un fichier <tt>Packages</>), il peut être suivi par un numéro de version entre parenthèses<footnote>En général, on laisse un espace après le nom du paquet si un numéro de version est spécifié.</footnote>. Ce numéro de version peut être omis (et l'est par <tt>dpkg- gencontrol</>) s'il a la même valeur que le champ <tt>Version</> du paquet binaire en question. Le champ lui-même peut être omis d'un fichier de contrôle d'un paquet binaire quand le paquet source possède le même nom et la même version que le paquet binaire. <sect1 id="fichierscontroles-2-6">Champs de relation entre paquets:<tt>Depends, Pre-Depends, Recommends, Suggest, Conflicts, Provides, Replaces</> Ces champs décrivent les relations du paquet avec les autres paquets. Leurs syntaxes et sémantiques sont décrites dans <ref id="relationpaquets">. <sect1 id="fichierscontroles-2-7">Description Dans un paquet binaire, dans le fichier <tt>Packages</> ou le fichier principal de contrôle du source, ce champs contient une description du paquet binaire, dans un format spécial. Voir <ref id="descriptpaquets"> pour les détails. Dans un fichier <tt>.changes</>, il contient un résumé de la description des paquets chargés. La partie du champ avant la première nouvelle ligne est vide; ensuite chaque ligne possède le nom d'un paquet binaire et la ligne de résumé de la description de ce paquet binaire. Chaque ligne est indentée par un espace. <sect1 id="fichierscontroles-2-8">Essential C'est un champ booléen qui peut apparaître seulement dans un fichier de contrôle d'un paquet binaire (ou dans le fichier <tt>Packages</>) ou dans un paragraphe de champs par paquet d'un fichier principal de données de contrôle de source. S'il est positionné à <tt>yes</> alors <tt>dpkg</> et <tt>dselect</> refuseront d'enlever ce paquet (bien qu'il puisse être mis à niveau et/ou déplacer). L'autre valeur possible est <tt>no</>, ce qui est la même chose que de n'avoir pas de champ du tout. <sect1 id="fichierscontroles-2-9">Section et Priority Ces deux champs classent le paquet. La <tt>Priority</> représente l'importance du paquet installé; la <tt>Section</> représente un zone d'application dans laquelle le paquet a été classifiée. Quand ces champs apparaissent dans le fichier <tt>debian/control</>, ils donnent les valeurs des sous-champs priorité et section du champ <tt>Files</> du fichier <tt>.changes</>, et donnent les valeurs par défaut de la section et de la priorité pour les paquets binaires. La section et la priorité sont représentées, même pas comme des champs séparés, dans les informations pour chaque fichier dans le champ <tt>Files</> d'un fichier <tt>.changes</>. La valeur de la section dans un fichier <tt>.changes</> est utilisée pour décider où sera installé le paquet dans une archive FTP. Ces champs ne sont pas utilisés par <tt>dpkg</>, mais par <tt>dselect</> quand il trie les paquets et sélectionne la valeurs par défaut. Voir le manuel des principes Debian pour les priorités en usage et les critères pour sélectionner les priorités pour les paquets Debian, et regarde une archive FTP Debian pour obtenir une liste des priorités courantes. Ces champs peuvent apparaître dans les fichiers de contrôle des paquets binaires, dans ce cas, ils fournissent une valeur par défaut au cas où les fichiers <tt>Packages</> ne possèdent pas l'information. <tt>dpkg</> et <tt>dselect</> n'utiliseront seulement la valeur d'un fichier <tt>.deb</> que s'ils n'ont pas d'autres informations; une valeur listée dans un fichier <tt>Packages</> sera toujours prioritaire. Par défaut <tt>dpkg-genchanges</> n'inclut pas la section et la priorité dans le fichier de contrôle d'un paquet binaire - utilise les options <tt>-isp, -is</> ou <tt>-ip</> pour réaliser cette opération. <sect1 id="fichierscontroles-2-10">Binary Ce champ est une liste de paquets binaires. Quand il apparaît dans un fichier <tt>.dsc</>, il représente la liste des paquets binaires qu'un paquet source peut produire. Il ne produit pas nécessairement tous ces paquets binaires pour chaque architecture. Le fichier de contrôle source ne contient pas les détails sur les architectures qui sont les plus appropriées pour les paquets binaires. Quand il apparaît dans un fichier <tt>.changes</>, il liste les noms des paquets binaires actuellement chargés. La syntaxe est une liste de paquets binaires séparée par des virgules<footnote>Par convention, il y a un espace après chaque virgule.</footnote>. Actuellement, les paquets doivent être séparés en utilisant seulement des espaces dans le fichier <tt>.changes</>. <sect1 id="fichierscontroles-2-11">Installed-size Ce champ apparaît dans les fichiers de contrôle des paquets binaires, et dans les fichiers <tt>Packages</>. Il donne la capacité totale du disque nécessaire pour installer le dit paquet. L'espace disque est représenté en Kilo-octets comme un nombre décimal simple. <sect1 id="fichierscontroles-2-12">Files Ce champ contient la liste des fichiers avec les informations sur chacun d'eux. L'information exacte et la syntaxe exacte varient avec le contexte. Dans tous les cas, la partie du contenu du champ sur la même ligne que le nom du champ est vide. Le reste du champ est une ligne par fichier, chaque ligne est indentée par un espace et contient un nombre de sous-champs séparés par des espaces. Dans le fichier <tt>.dsc</> (contrôle des sources Debian), chaque ligne contient la somme de contrôle MD5, la taille et le nom du fichier tar et (éventuellement) le fichier diff qui représente le reste du paquet source<footnote>C'est la partie qui n'est pas <tt>.dsc</>.</footnote>. Les formes exactes des noms de fichier sont décrites dans <ref id="paquetssources-3">. Dans le fichier <tt>.changes</>, il contient une ligne par fichier chargé. Chaque ligne contient la somme de contrôle, la taille, la section et la priorité et le nom du fichier. La section et la priorité sont les valeurs des champs correspondants dans le fichier principal de contrôle source - voir <ref id="fichierscontroles-2-9">. Si aucune section ou priorité n'est spécifiée alors <tt>-</> doit être utilisé, bien que les valeurs de section et de priorité doivent être spécifiées pour installer proprement les nouveaux paquets. La valeur spéciale <tt>byhand</> pour la section dans un fichier <tt>.changes</> indique que le fichier en question n'est pas un fichier ordinaire de paquet et doit être installé à la main par les mainteneurs de la distribution. Si la valeur de la section est <tt>byhand</> alors la valeur de la priorité devrait être <tt>-</>. Si une nouvelle révision Debian d'un paquet est chargée et qu'aucune archive originale source n'est distribuée, le fichier <tt>.dsc</> doit toujours contenir l'entrée du champ <tt>Fields</> pour l'archive originale source package-upstream-version</><tt>.orig.tar.gz</> mais le fichier <tt>.changes</> devrait l'omettre. Dans ce cas, l'archive originale source sur le site de distribution doit être exactement, octet par octet, l'archive originale source qui a été utilisée pour générer le fichier <tt>.dsc</> et le fichier diff qui a été chargé. <sect1 id="fichierscontroles-2-13">Standards-Version Ce champ contient la version la plus récente des standards (les manuels des principes et du programmeur dpkg et les textes associés) auxquels le paquet se conforme. Le champ est mis à jour manuellement lors de l'édition du paquet source pour se conformer aux nouveaux standards; il peut parfois être utilisé pour signaler qu'un paquet a besoin d'une attention particulière. Son format est le même que le numéro de version sauf que epoch et la révision Debian ne sont pas autorisés - voir <ref id="numeroversions">. <sect1 id="fichierscontroles-2-14">Distribution Dans un fichier <tt>.changes</> ou dans la sortie analysée de changelog, ce champ contient le ou les noms (séparés par des espaces) de la ou les distributions où cette version du paquet devrait être ou a été installée. Les noms de distribution suivent les règles des noms de paquets (voir <ref id="fichierscontroles-2-1">). Les valeurs des distributions courantes sont: <taglist> <tag>stable <item>C'est la version courante mise à jour de Debian GNU/Linux. Une nouvelle version apparaît approximativement tous les 3 mois après que le code de développement</> ait été gelé</> pendant un mois de test. Une fois que la distribution est stable</>, seule la correction d'erreurs majeures est autorisée. Quand les changements sont faits sur cette distribution, le chiffre mineur de la version est incrémenté (par exemple: 1.2 devient 1.2.1 puis 1.2.2, etc). <tag>unstable <iem>Cette valeur de distribution fait référence à une partie en cours de développement de l'arbre de distribution Debian. Les nouveaux paquets, les nouvelles versions de paquets et la correction d'erreur vont dans le répertoire unstable</>. Travailler avec cette distribution est de ta seule responsabilité. <tag>contrib <item>Les paquets avec cette valeur de distribution ne respectent pas les critères pour être inclus dans la distribution principale Debian comme défini dans le manuel des principes, mais respectent les critères pour une distribution contrib</>. Il n'y a actuellement aucune distinction entre les paquets stable</> et unstable</> dans les distributions contrib</> et non-free</>. Utilise à bon escient le chargement de cette distribution. <tag>non-free <item>Comme les paquets de la section contrib</>, les paquets dans la distribution non-free</> ne respectent pas certains critères pour pouvoir être inclus dans la distribution principale Debian comme défini dans la manuel des principes. De nouveau, utilise à bon escient cette distribution. <tag>experimental <item>Les paquets de cette valeur de distribution sont considérés par leur mainteneur comme étant risqué. Souvent, ils représentent les paquets en béta-test ou en cours de développement provenant de sources variées que le mainteneurs veut faire tester, mais ne sont pas prêt pour être inclus dans l'arbre de distribution Debian. A utiliser à tes risques et périls. <tag>frozen <item>De temps en temps, (généralement, tous les 3 mois) la distribution unsable</> rentre dans un état 'gelé' dans l'attente d'une version stable</>. Pendant cette période de test (habituellement 4 semaines), seules les corrections d'erreurs existantes ou récemment découvertes sont autorisées. </taglist> Tu devrais lister toutes</> les distributions où le paquet devrait être installé. Sauf dans des circonstances inhabituelles; les installations vers stable</> doivent aussi aller dans frozen</> (si il existe) et dans unstable</>. De même, les installations dans frozen</> devraient aussi aller dans unstable</>. <sect1 id="fichierscontroles-2-15">Urgency Ce champ est une description de l'importance d'une mise à jour d'une version à l'autre. Il contient un simple mot-clé qui prend habituellement une de ces valeurs <tt>LOW, MEDIUM</> ou <tt>HIGH</> suivi par un commentaire optionnel (séparé par un espace) qui est généralement entre parenthèses. Par exemple: <example> Urgency: LOW (HIGH for diversions users) </example> Ce champ apparaît dans le fichier <tt>.changes</> et dans les changelogs analysées; sa valeur apparaît comme valeur de l'attribut <tt>urgency</> dans le changelog de <tt>dpkg</>-style (voir <ref id="paquetssources-2-2">). Les mots-clé ne sont pas sensibles au majuscule/minuscule. <sect1 id="fichierscontroles-2-16">Date Dans les fichiers <tt>.changes et les changelogs analysés, ce champ donne la date de la construction de paquet ou de la dernière édition. <sect1 id="fichierscontroles-2-17">Format Le champ apparaît dans les fichiers <tt>.changes</>, et spécifie une révision de format pour le fichier. Le format décrit ici est la version <tt>1.5</>. La syntaxe de la valeur du format est la même que la numérotation de la version des paquets, sauf que epoch et la révision Debian ne sont pas autorisés - voir <ref id="numeroversions">. <sect1 id="fichierscontroles-2-18">Changes Dans un fichier <tt>.changes</> ou dans un changelog analysé, ce champ contient les données lisibles des changements, décrivant les différences entre la dernière version et celle courante. Il ne doit rien y avoir dans ce champ avant le première nouvelle ligne; toutes les lignes suivantes doivent être indentées par au moins un espace; les lignes vides doivent être représentées par une ligne contenant seulement un espace et un point. Chaque information de changement de version doit être précédée par une ligne de 'titre' donnant au moins la version, la ou les distributions et l'urgence, d'une façon lisible. Si les données de plusieurs versions sont retournées, l'entrée de la plus récente version doit être retournées d'abord, et les entrées doivent être séparées par une ligne vide (la ligne de 'titre' peut aussi être suivi par une ligne vide). <sect1 id="fichierscontroles-2-19">Filenames et MSDOS-Filename Ces champs dans les fichiers <tt>Packages</> donnent les noms de fichiers d'un paquet dans une distribution, par rapport à la racine de la hiérarchie Debian. Si le paquet a été découpé en plusieurs morceaux, les parties sont toutes listées dans l'ordre, séparées par des espaces. <sect1 id="fichierscontroles-2-20">Size et MD5sum Ces champs dans les fichiers <tt>Packages</> donnent la taille (en octets, exprimée en décimal) et la somme de contrôle MD5 du ou des fichiers qui composent le paquet de la distribution. Si le paquet est découpé en plusieurs parties, les valeurs pour ces parties sont listées dans l'ordre, séparées par des espaces. <sect1 id="fichierscontroles-2-21">Status Ce champ dans le fichier status de <tt>dpkg</> enregistre si l'utilisateur veut un paquet installé, enlevé ou laissé tout seul, si il est incorrect (nécessite une réinstallation) ou non et son état courant sur le système. Chaque morceau de ces informations est un simple mot. <sect1 id="fichierscontroles-2-22">Config-version Si un paquet n'est pas installé, ou non configuré, ce champ dans le fichier status de <tt>dpkg</> enregistre la dernière version de ce paquet qui a été configuré avec succès. <sect1 id="fichierscontroles-2-23">Conffiles Ce champ dans le fichier status de <tt>dpkg</> contient les informations sur les fichiers de configuration automatiquement gérés maintenus par un paquet. Ce champ ne doit pas</> apparaître n'importe où dans un paquet! <sect1 id="fichierscontroles-2-24">Champs obsolètes Ils sont toujours reconnus par <tt>dpkg</> mais ne doivent plus apparaître n'importe où. <taglist> <tag>Revision <item> <tag>Package-Revision <item> <tag>Package_Revision <item>La partie revision Debian d'une version de paquet était à un moment dans un champ de fichier de contrôle séparé. Ce champ était présent à travers plusieurs noms. <tag>Recommended <item>Ancienne dénomination pour <tt>Recommends</>. <tag>Optional <item>Ancienne dénomination pour <tt>Suggests</>. <tag>Class <item>Ancien nom pour <tt>Priority</>. </taglist> <chapt id="numeroversions">Numérotation des versions Chaque paquet a un numéro de version, dans son champ <tt>Version</> du fichier de contrôle. <tt>dpkg</> impose un ordre sur les numéros de version, afin de savoir si les paquets sont nouveaux ou anciens et afin que <prgn/dselect/ puisse dire si un des paquets qu'il a trouvé est plus récent que celui installé sur le système. La partie la plus significative dans le format de numéro de version se trouve au début. Le format de numéro de version est: <example> [epoch:]version-originale[<tt>-</>révision-debian] </example> Les trois composants sont: <taglist> <tag> epoch <item> Un entier non signé simple, qui doit toujours être petit. Il peut être omis, dans ce cas, il est considéré à 0. S'il est omis, le champ version-originale</> ne peut pas contenir la ponctuation :. Il est fourni pour autoriser des erreurs dans les numéros de version des vieilles versions de paquet, et aussi pour abandonner une structure précédente de numérotation de version de paquet. <tt>dpkg</> n'affiche pas habituellement le champ epoch</>, à moins qu'il ne soit essentiel (différent de 0, ou si le champ version-originale</> contient la ponctuation :), <prgn/dselect/ n'affiche pas le champ epoch</> du tout dans la partie principale d'un affichage de sélection de paquet. <tag> version-originale <item> C'est la partie principale de la version. C'est d'habitude le numéro de la version originale du paquet à partir duquel le fichier <tt>.deb</> a été crée, si c'est possible. Généralement, ce champ est dans le même format que celui spécifié par l'auteur original, cependant, il peut être si nécessaire, reformaté pour rentrer dans le format <tt>dpkg</> et la structure de comparaison. Le comportement de la comparaison de <tt>dpkg</> en respect avec le champ version-originale</> est décrit ci-dessous. La portion du champ version-originale</> du numéro de version est obligatoire. Le champ version-originale</> ne peut contenir seulement des caractères alphanumériques et les caractères <tt>+ . - :</> et doit commencer par un chiffre. S'il n'y a pas de champ révision-debian</> alors le tiret (-) n'est pas autorisé. S'il n'y a pas le champ epoch</> alors les : ne sont pas autorisés. <tag> révision-debian <item> Cette partie de la version représente la version des modifications qui ont été faites au paquet pour en faire un paquet Debian. Elle est dans le même format que le champ version-originale</> et <tt>dpkg</> la compare de la même façon. Ce champ est optionnel. S'il n'est pas présent alors le champ version-originale</> ne peut contenir de tirer (-). Ce format représente le cas où un morceau de code a été écrit spécialement pour obtenir le paquet binaire Debian. S'il n'y a qu'une seule et plus débianisation du paquet, aucune indication de révision n'est nécessaire. Par convention, le champ révision-debian</> est remis à 1 à chaque fois que le champ version-originale</> est incrémenté. <tt>dpkg</> coupera en deux, les champs version-originale</> et révision-debian</> au dernier tiret dans le numéro de version. L'absence du champ révision-debian</> est comparée plus tôt que la présence de ce champ (mais le champ révision-debian</> est la partie la moins significative du numéro de version). Le champ révision-debian</> peut contenir seulement des caractères alphanumériques et les caractères (<tt>+ .</>). </taglist> Les champs version-originale</> et révision-debian</> sont comparés par <tt>dpkg</> en utilisant le même algorithme. Les chaînes sont comparées de gauche à droite. D'abord la partie initiale de chaque chaîne, qui consiste entièrement de caractères sans chiffre, est déterminée. Ces deux parties sont comparées lexicalement. Si une différence est trouvée, elle est retournée. La comparaison lexicale est une comparaison de valeurs ASCII modifiées afin que toutes les lettres soient triées plus tôt que les chiffres et caractères de ponctuation. Ensuite, la partie initiale du reste de chaque chaîne qui consiste entièrement de chiffre est déterminée. La valeur numérique de ces deux parties est comparée, la différence est retournée comme résultat de la comparaison. C'est dans ce but, qu'une chaîne vide (qui apparaît seulement à la fin de l'une ou des deux chaînes comparées de version) compte pour un zéro. Ces deux phases sont répétées (en enlevant du début de la chaîne les caractères et les chiffres) jusqu'à ce qu'une différence soit trouvée ou que les deux chaînes soient terminées. Le but du champ epoch</> est d'inhiber les erreurs de numérotation de version, et de s'arranger avec les situations où la numérotation de version change. Il ne sert pas à corriger les numéros de version contenant des chaînes de caractères que <tt>dpkg</> ne peut pas interpréter (tel que <tt>ALPHA</> ou <tt>pre-</>) ou une numérotation bâtarde (l'auteur du manuel original a entendu qu'un paquet avait une version <tt>1.1.1.2</>, <tt>1.3</>, <tt>1</>, <tt>2.1</>, <tt>2.2</>, <tt>2</> et ainsi de suite). Si un paquet original a un problème de numérotation de version, il doit être converti dans un format sain pour être utilisé dans le champ <tt>Version</>. Si tu as besoin de comparer les numéros de version dans un script, tu peux utiliser <prgn/dpkg --compare-versions .../. Voir <prgn/dpkg --help/ pour avoir plus de détails sur les arguments. ************************************************************** <chapt id="scriptmaintenance">Script de maintenance de paquet et procédure d'installation</> <sect id="scriptmaintenance-1">Introduction aux scripts de gestion de paquet Il est possible de fournir des scripts avec le paquet que <tt>dpkg</> exécutera pour toi quand ton paquet est installé, mis à jour ou enlevé. Ces scripts s'appellent <tt>preinst, postinst, prerm</> et <tt>postrm</> dans la zone de contrôle du paquet. Ce sont des fichiers exécutables propres; si ce sont des scripts (ce qui est recommandé), ils doivent commencer par la convention habituelle <tt>#!</>. Ils doivent être lisible et exécutable par n'importe qui, et non modifiable. <tt>dpkg</> teste le statut de sortie de ces scripts. Il est important qu'ils se terminent avec un statut différent de zéro, s'il y a une erreur, afin que <tt>dpkg</> puisse arrêter son traitement. Pour les scripts shell, ceci signifie que tu as presque toujours besoin d'utiliser <tt>set -e</> (ce qui est généralement vrai quand on écrit des scripts shell, en fait). Il est aussi important, bien sûr, qu'ils ne se terminent pas avec un statut différent de zéro si tout se passe bien. Il est nécessaire pour les procédures de recouvrement d'erreurs que les scripts soient idempotents; c'est à dire, appeler le même script plusieurs fois dans la même situation ne doit pas provoquer de problèmes. Si le premier appel échoue, ou s'arrête au milieu du chemin pour une raison ou une autre, le second appel devrait faire les choses qui n'ont pas été faites la première fois, s'il y en a, et sortir avec succès. Quand un paquet est mis à jour, une combinaison des scripts du vieux et du nouveau paquet est appelée dans presque toutes les autres étapes de la procédure de mise à jour. Si tes scripts sont devenus plus compliqués, tu dois faire attention à cela, et peut être vérifier les arguments de tes scripts. Techniquement parlant, le script <tt>preinst</> est appelé avant d'installer (une version particulière de) un paquet, et <tt>postinst</> après; le script <tt>prerm</> avant d'effacer (une version de) un paquet et <tt>postrm</> après. Les programmes appelés à partir des scripts ne devraient pas normalement avoir de chemin préfixé. Avant que l'installation démarre, <tt>dpkg</> vérifie pour voir si les programmes <tt>ldconfig, start-stop-daemon, install-info</> et <tt>update-rc.d</> peuvent être trouvés via la variable d'environnement <tt>PATH</>. Ces programmes, et n'importe quel autre programme qu'on s'attend à trouver dans le <tt>PATH</>, devraient donc être appelés sans nom de chemins absolu. Les scripts de maintenance ne devraient pas non plus réinitialiser le <tt>PATH</>, bien qu'ils peuvent choisir de le modifier en ajoutant devant ou à la fin un répertoire spécifique à un paquet. Ces considérations s'appliquent vraiment à tous les scripts shell. <sect id="scriptmaintenance-2">Résumé des façons dont les scripts de maintenance sont appelés <list> <item> nouveau-preinst</> <tt>install</> <item> nouveau-preinst</> <tt>install</> vieille-version</> <item> nouveau-preinst</> <tt>upgrade</> vieille-version</> <item> vieux-preinst</> <tt>abort-upgrade</> nouvelle-version</> </list> <list> <item> postinst</> <tt>configure</> version-configurée-plus- récemment</> <item> vieux-postinst</> <tt>abort-upgrade</> nouvelle-version</> <item> postinst-conflictuel</> <tt>abort-remove in-favour</> paquet nouvelle-version</> <item> postinst-déconfiguré</> <tt>abort-deconfigure in-favour</> paquet-installation-échoué version</> <tt>removing</> paquet- conflictuel version</> </list> <list> <item> prerm</> <tt>remove</> vieille-version</> <item> vieux-prerm</> <tt>upgrade</> nouvelle-version</> <item> nouveau-prerm</> <tt>failed-upgrade</> nouvelle-version</> <item> postrm-conflictuel</> <tt>remove in-favour</> paquet nouvelle-version</> <item> postrm-déconfiguré</> <tt>deconfigure in-favour</> paquet-installé version</> <tt>removing</> paquet- conflictuel version</> </list> <list> <item> postrm</> <tt>remove</> <item> postrm</> <tt>purge</> <item> vieux-postrm</> <tt>upgrade</> nouvelle-version</> <item> nouveau-postrm</> <tt>failed-upgrade</> vieille-version</> <item> nouveau-postrm</> <tt>abort-install</> <item> nouveau-postrm</> <tt>abort-install</> vieille-version</> <item> nouveau-postrm</> <tt>abort-upgrade</> vieille-version</> <item> postrm-disparu</> <tt>disappear</> ecraseur nouvelle-version</> </list> <sect id="scriptmaintenance-3">Détails des phases d'installation et de mise à jour La procédure sur installation/mis à jour/écrasement/effacement (c'est à dire en exécutant <tt>dpkg --unpack</>, ou l'étape unpack de <tt>dpkg -- install</>) est la suivante. Dans chaque cas, si un erreur se produit, les actions sont généralement exécuter en arrière - ce qui signifie que les scripts de maintenance sont exécutés avec des arguments différents dans l'ordre inverse. Ce sont les appels 'recouvrement d'erreur' listés ci- dessous. <enumlist> <item> <enumlist> <item>Si une version du paquet est déjà installée, appel <example> vieux-prerm</> <tt>upgrade</> nouvelle-version</> </example> <item>Si cela donne une erreur (c'est à dire un status de fin différent de zéro), dpkg essayera plutôt: <example> nouveau-prerm</> <tt>failed-upgrade</> vieille-version</> </example> Recouvrement d'erreurs, dans les deux cas ci-dessus: <example> vieux-postinst</> <tt>abort-upgrade</> nouvelle-version</> </example> </enumlist> <item>Si un paquet conflictuel est enlevé en même temps: <enumlist> <item>Si n'importe quels paquets dépend de ce paquet conflictuel et <tt>--auto-deconfigure</> est spécifié, appel pour chaque paquet: <example> prerm-déconfiguré</> <tt>deconfigure in-favour</> paquet-installé version</> <tt>removing</> paquet-conflictuel version</> </example> Recouvrement d'erreurs: <example> postrm-déconfiguré</> <tt>abort-deconfigure in-favour</> paquet-échoué-installé version</> <tt>removing</> paquet-conflictuel version</> </example> Les paquets déconfigurés sont indiqués comme nécessitant une configuration, afin que si <tt>--install</> est utilisé, ils seront configurés de nouveau, si possible. <item>Pour préparer, l'effacement du paquet conflictuel, appel: <example> prerm-conflictuel</> <tt>remove in-favour</> paquet nouvelle-version</> </example> Recouvrement d'erreurs: <example> postinst-conflictuel</> <tt>abort-remove in-favour</> paquet nouvelle-version</> </example> </enumlist> <item> <enumlist> <item>Si le paquet est mis à jour, appel: <example> nouvelle-preinst</> <tt>upgrade</> vieille-version</> </example> <item>Autrement si le paquet a des fichiers de configuration d'une version précédemment installée (c'est à dire, il ne reste plus que les fichiers de configuration): <example> nouveau-preinst</> <tt>install</> vieille-version</> </example> <item>Autrement (c'est à dire, le paquet a été complètement effacé): <example> nouveau-preinst</> <tt>install</> </example> Les versions de recouvrement d'erreurs, respectivement: <example> nouveau-postrm</> <tt>abort-upgrade</> vieille-version</> nouveau-postrm</> <tt>abort-install</> vieille-version</> nouveau-postrm</> <tt>abort-install</> </example> </enumlist> <item>Les nouveaux fichiers du paquet sont installé, écrasant ceux qui peuvent déjà être sur le système, par exemple, les fichiers d'une vieille version du même paquet ou d'un autre paquet (les sauvegardes des vieux fichiers sont là, et si quelque chose se passe mal, dpkg essayera de les remettre à leur place dans la partie de recouvrement d'erreurs). C'est une erreur pour un paquet de contenir des fichiers qui sont sur le système dans d'autre paquet, à moins que <tt>Replaces</> soit utilisé (voir <ref id="relationpaquets-5">). Pour l'instant l'option <tt>--force-overwriting</> est disponible, le dégradant en un avertissement, mais ce ne sera pas toujours le cas. C'est une erreur beaucoup plus grave pour un paquet de contenir un fichier ou autre chose qu'un répertoire où un autre paquet a un répertoire (de nouveau, à moins que <tt>Replaces</> ne soit utilisé). Cette erreur peut être éviter si c'est l'effet recherché, en utilisant <tt>--force-overwrite-dir</>, mais ce n'est pas conseillé. Les paquets qui s'écrasent mutuellement des fichiers produisent des comportements qui bien que déterministe est difficile à comprendre pour un administrateur système. Cela nous amène à des programmes "manquants" si par exemple, un paquet est installé qui écrase un fichier d'un autre paquet, et puis est effacé de nouveau<footnote>Une partie du problème vient d'une erreur de <tt>dpkg</>.</footnote>. Un répertoire ne sera jamais remplacé par un lien symbolique vers un répertoire et vice versa; à la place, l'état existant (lien symbolique ou non) est conservé et <tt>dpkg</> suivra les liens s'il y en a. <item> <enumlist> <item>Si le paquet est mis à jour, appel: <example> vieux-postrm</> <tt>upgrade</> nouvelle-version</> </example> <item>Si cela échoue, <tt>dpkg</> essayera: <example> nouveau-postrm</> <tt>failed-upgrade</> vieille-version</> </example> Les recouvrements d'erreur, dans les deux cas: <example> vieux-preinst</> <tt>abort-upgrade</> nouvelle-version</> </example> C'est le point de non retour - si <tt>dpkg</> atteint ce point, il ne reviendra pas en arrière de ce point, si une erreur survient. Ceci laissera le paquet dans un mauvais état, qui nécessitera une réinstallation réussie pour remettre en état, mais c'est quand <tt>dpkg</> commence à faire des choses irréversibles. </enumlist> <item>Tous les fichiers qui étaient dans la version précédent du paquet, mais pas dans le nouveau, sont effacés. <item>La nouvelle liste de fichiers remplace la précédente. <item>Les nouveaux scripts de maintenance remplacent les anciens. <item>Les paquets dont les fichiers ont été écrasés pendant l'installation, et qui ne sont pas nécessaires pour les dépendances, sont considérés comme effacés. Pour ce paquets: <enumlist> <item><tt>dpkg</> appelle: <example> postrm-disparu</> <tt>disappear</> ecraseur version-ecraseur</> </example> <item>Les scripts de maintenance du paquet son effacés. <item>Il est inscrit dans la base de données des statuts comme étant dans un état incorrect, non installé (ses fichiers de config sont ignorés plutôt que d'être enlevé par <tt>dpkg</>). Remarque que ce paquet disparu n'a pas appelé son script prerm, car <tt>dpkg</> ne sait pas à l'avance que le paquet est écrasé. </enumlist> <item>Les fichiers du paquet qui sont aussi listés dans les listes de fichiers des autres paquets sont enlevés de ces listes (ce qui lobotomisera la liste de fichiers du paquet conflictuel, s'il y en a un). <item>Les fichiers de sauvegarde faits pendant l'installation, ci- dessus, sont effacés. <item>Le nouveau statuts du paquet est correct et enregistré comme installé. C'est un autre point de non retour - si l'effacement d'un paquet conflictuel échoue, nous ne pouvons pas défaire le reste de l'installation; le paquet conflictuel est dans un état à moitié enlevé. <item>S'il y avait un paquet conflictuel, nous avons utilisé les actions d'effacement (décrites ci-dessus), en commençant par l'effacement des fichiers conflictuels du paquet (les fichiers qui sont aussi dans le paquet installé ont déjà été effacés de la liste des fichiers conflictuels du paquet, et ne doivent pas être enlevés maintenant). </enumlist> <sect id="scriptmaintenance-4">Détails de la configuration Quand nous configurons un paquet (ceci arrive avec <tt>dpkg -- install</>, ou avec <tt>--configure</>), nous mettons à jour d'abord les fichiers de configuration (conffiles) et ensuite appelons: <example> posinst</> <tt>configure</> version-configurée-la-plus- récente</> </example> Aucune actions n'est tenté pour défaire les erreurs pendant la configuration. S'il n'y a pas de version configurée plus récente, <tt>dpkg</> passera un argument nul; les vieilles versions de <tt>dpkg</> peuvent passer <tt/<unknow>/ (avec les signes supérieur et inférieur) dans ce cas. Même les plus vieux ne passent pas de second argument du tout, dans n'importe quelles circonstances. <sect id="scriptmaintenance-5">Détails de l'effacement et/ou de la configuration de purge <enumlist> <item> prerm</> <tt>remove</> <item> Les fichiers du paquet sont effacés (sauf conffiles). <item> postrm</> <tt>remove</> <item> Tous les scripts de maintenance sont effacés sauf postrm. Si nous n'effaçons pas le paquet, la procédure s'arrête là. Remarque que les paquets qui n'ont pas de postrm et conffiles sont automatiquement purgés pendant l'effacement, comme il n'y pas de différence, sauf pour le statut de <tt>dpkg</>. <item>Le conffiles et les fichiers de sauvegarde (-files, <tt>#*#</>files, %-files, <tt>.dpkg-{old, new, tmp}</>, etc.) sont effacés. <item>postrm</> <tt>purge</> <item>La liste des fichiers du paquet est effacée. </enumlist> Aucune tentative n'est faite pour défaire les erreurs durant l'effacement. <chapt id="descriptpaquets">Description des paquets - le champ <tt>Description</> Le champ <tt>Description</> du fichier de contrôle est utilisé par <prgn/dselect/ quand l'utilisateur est en train de sélectionner les paquets à installer et par <prgn/dpkg/ quand il affiche les informations sur les statuts des paquets et ainsi de suite. Il est inclus sur les sites FTP dans les fichiers <tt>Packages</>, et peut être aussi utilisé sur les pages Web Debian. La description permet de décrire le programme à l'utilisateur qui n'en avait jamais entendu parler auparavant, afin de savoir s'il veut l'installer. Elle doit donner des informations sur les conflits et dépendances significatives entre ce paquet et les autres, afin que l'utilisateur sache pourquoi ces conflits et dépendances ont été déclarés. Le champ a le format suivant: <example> <tt>Description:</> Une seule ligne de résumé description étendue sur plusieurs lignes </example> Le résumé est souvent affiché dans les listes de paquets et autres, et doit être aussi instructif que possible. Chaque paquet doit aussi avoir une description détaillée (étendue). <sect id="descriptpaquets-1">Types de lignes formatées dans la description étendue <list> <item>Les lignes commençant par un simple espace, sont des parties de paragraphe. Les lignes successives de cette forme seront formatées à l'affichage. L'espace en trop sera habituellement supprimé. <item>Les lignes commençant par deux (ou plus) espaces seront affichées telles quelles. Si l'affichage n'est pas extensible horizontalement, le programme d'affichage s'occupera de leur sort (c'est à dire sans prendre en compte les coupures de mots). Si c'est possible, elles seront autorisées à s'estomper à droite. Aucun, un ou deux espaces peuvent être effacés, mais le nombre d'espace, effacés de chaque ligne, doit être le même (afin d'indenter le travail correctement, par exemple). <item>Les lignes contenant un seul espace, suivi par un seul point sont considérées comme des lignes vides. C'est la seule manière d'avoir des lignes vides, voir ci-dessous. <item>Les lignes contenant un espace, un point et d'autres caractères sont prévues pour des extensions futures. Ne pas les utiliser. </list> <sect id="descriptpaquets-2">Remarques sur l'écriture des descriptions Commencer toujours les lignes de description étendue par au moins un espace. Les champs dans les fichiers de contrôle et les fichiers <tt>Packages</> sont séparés par des noms de champ qui commencent sur la première colonne, comme le sont les champs d'en-tête de message dans la RFC 822. Oublier les espaces provoquera de la part de <prgn/dpkg-deb/ <footnote>version 0.93.23 et suivantes.</footnote> une erreur de syntaxe quand il essayera de construire le paquet. Si tu forces la construction, <prgn/dpkg/ refusera d'installer le désordre. Ne pas inclure de lignes complètement vides. Elles servent à séparer les différents enregistrements dans le fichiers <tt>Packages</> et différents paquets dans le fichier <tt>debian/control</> et sont interdites dans les fichiers de contrôle de paquets. Voir le paragraphe précédent pour connaître les effets sur <prgn/dpkg/. La ligne de résumé doit être brève, moins de 80 caractères. <prgn/dselect/ affiche entre 25 et 49 caractères sans déborder, si tu utilises un terminal de 80 colonnes, dépendant des options d'affichage. Ne pas inclure le nom du paquet dans la ligne de résumé. Le logiciel sait déjà l'afficher, et ce n'est pas nécessaire de s'en occuper. Ne pas oublier que dans beaucoup de cas, l'utilisateur ne regarde seulement que la ligne de résumé, il faut donc la rendre aussi instructive que possible. La description étendue doit décrire ce que fait le paquet, et comment il est relié au reste du système (en termes, par exemple, de sous-système, de partie de ...). Le commentaire, qui est fourni avec un programme dans ses fichiers d'annonces et/ou <tt>README</>, est rarement approprié pour une utilisation dans une description. Il est habituellement conçu pour les gens qui connaissent déjà le paquet. Le champ de description doit être compris par n'importe qui, même pour les gens qui n'ont aucune idée sur ce que fait le paquet. Mettre les informations importantes d'abord, dans le résumé et dans la description étendue. Quelques fois, seulement, la première partie du résumé ou de la description sera affichée. On peut supposer qu'il y a d'habitude une manière de voir l'ensemble de la description étendue. Tu dois inclure les informations sur les dépendances et autres, dans la description étendue, si tu le souhaites. Ne pas utiliser le caractère de tabulation, son effet est imprévisible. Ne pas essayer de couper la ligne du résumé (la partie sur la même ligne que le champ description) dans la description étendue. Cela ne fonctionnera pas correctement quand la description complète sera affichée et n'aura aucun sens aux endroits où seul le résumé est disponible. <sect id="descriptpaquets-3">Exemple de description dans le fichier de contrôle de Smail <example> Package: smail Version: 3.1.29.1-13 Maintener: Ian Jackson <iwj10@cus.cam.ac.uk> Recommends: pine | mailx | elm | emacs | mail-user-agent Suggests: metamail Depends: cron, libc5 Conflicts: sendmail Provides: mail-transport-agent Description: Electronic mail transport system. Smail is the recommended mail transport agent (MTA) for Debian. . An MTA is the innards of the mail system - it takes messages from user-friendly mail programs and arranges for them to be delivred locally or passed on to other systems as required. . In ordre to make use of it you must have one or more user level mailreader programs such as elm, pine, mailx, or Emacs (which has Rmail and VM as mailreaders) installed. If you wish to send messages other than just to other users of your system you must also have appropriate networking support, in the form of IP or UUCP. </example> ****************************************************************** <chapt id="relationpaquets">Déclaration des relations entre les paquets Les paquets peuvent déclarer dans leur fichier de contrôle qu'ils ont certaines relations avec d'autres paquets - par exemple, qu'ils ne peuvent pas être installés en même temps que certains autres paquets, et/ou qu'ils dépendent de la présence d'autres, ou qu'ils doivent écraser les fichiers dans certains autres paquets s'ils sont présents. Ceci est effectué en utilisant les champs du fichier de contrôle <tt>Depends, Recommends, Sugggests, Conflicts, Provides</> et <tt>Replaces</>. <sect id="relationpaquets-1">La syntaxe des champs de relations Ces champs ont tous la même syntaxe uniforme. Ce sont des listes de noms de paquets séparées par des virgules. Dans <tt>Depends, Recommends, Suggests</> et <tt>Pre-Depends</> (les champs qui déclarent les dépendances du paquets dans lesquelles elles apparaissent dans d'autres paquets), ces noms de paquet peuvent aussi être des listes de noms de paquets alternatifs, séparés par des symboles barre verticale | (symbole du tube de communication). Tous les champs sauf <tt>Provides</> peuvent restreindre leur application à des versions particulières de chaque paquet nommé. C'est indiqué entre parenthèses après chaque nom individuel de paquet; les parenthèses devraient contenir une relation de la liste ci-dessous suivie par un numéro de version, dans le format décrit dans <ref id="numeroversions">. Les relations autorisées sont <tt/<<, <=, = >=/ et <tt/>>/ pour strictement avant, avant ou égal, égal, après ou égal, strictement après, respectivement. Les formes <tt/</ et <tt/>/ ont été utilisées pour signifier avant/après ou égal, plutôt que strictement avant/après, ainsi ils ne doivent pas apparaître dans les nouveaux paquets (bien que <tt>dpkg</> les supporte toujours). Les espaces peuvent apparaître n'importe où dans la spécification de version, et doivent apparaître où cela est nécessaire pour désambiguïser; autrement ils ne sont pas significatifs. Pour l'uniformité et dans le cas de futurs changements à <tt>dpkg</>, il est recommandé qu'un seule espace soit utilisé après une relation de version et avant un numéro de version; il est aussi convenu de mettre un espace après chaque virgule, de chaque côté d'une barre verticale, et avant chaque parenthèse ouvrante. Par exemple: <example> Package: metamail Version: 2.7-3 Depends: libc5 (>= 5.2.18-4), mime-support, csh | tcsh </example> <sect id="relationpaquets-2">Les dépendances - <tt>Depends, Recommends, Suggests, Pre- Depends</> Ces quatre champs sont utilisés pour déclarer une dépendance d'un paquet sur un autre. Ils apparaissent dans le fichier de contrôle dépendant du paquet. Tous, sauf <tt>Pre-Depends</> (voir ci-dessous) prennent effet seulement quand un paquet est configuré. Ils n'empêchent pas un paquet d'être sur le système dans un état non configuré alors que ses dépendances sont non satisfaites, et il est possible de remplacer un paquet dont les dépendances sont satisfaites et qui est proprement installé par une version différente dont les dépendances ne sont pas et ne peuvent pas être satisfaites; quand c'est le cas, le paquet dépendant sera laissé non configuré (étant donnée que les tentatives pour le configurer, donneront des erreurs) et ne fonctionnera pas correctement. Pour cette raison, les paquets dans une installation sont généralement tous installés d'abord et tous configurés ensuite; ceci donne les dernières versions des paquets avec les dépendances sur les dernières versions des autres paquets, l'opportunité d'avoir leurs dépendances satisfaites. Ainsi <tt>Depends</> autorise les mainteneurs de paquets d'imposer un ordre sur la configuration des paquets. <taglist> <tag>Depends <item>Ceci déclare une dépendance absolu. <dpkg> ne configurera pas les paquets dont les dépendances ne sont pas satisfaites. S'il est demandé de faire une installation qui ne satisfait pas les dépendances d'un paquet installé, il produira une erreur<footnote>la version 1.2.4 de <tt>dpkg</> a une erreur qui ne permet pas de prendre en compte ces problèmes.</footnote>, à moins que <tt>--auto-deconfigure</> ne soit spécifié, dans quel cas, ces paquets seront déconfigurés avant la procédure d'installation. <tt>dselect</> rend difficile pour l'utilisateur la sélection des paquets pour l'installation, l'effacement ou la mise à jour de façon à ce que les champs <tt>Depends</> des paquets soient insatisfaits. L'utilisateur peut écraser cela s'il veut, par exemple s'ils savent que <tt>dselect</> a une vue périmée des relations réelles des paquets. Le champ <tt>Depends</> devrait être utilisé si le paquet d'appui est nécessaire pour le paquet dépendant pour fournir une quantité significative de fonctionnalités. <tag>Recommends <item>ceci déclare une forte, mais pas absolue, dépendance. <tt>Recommends</> est ignoré par <tt>dpkg</>, afin que les utilisateurs utilisant la ligne de commande (en supposant savoir ce qu'ils font) ne soient pas gênés. Il est traité par <tt>dselect</> exactement comme <tt>Depends</>; ce qui rend difficile pour l'utilisateur de sélectionner les choses de façon à laisser les champs <tt>Recommends</> non satisfaits, mais ils sont capable de le faire en étant persistent. Le champ <tt>Recommends</> devrait lister les paquets qui devraient être liés entre eux à celui-ci pour tout sauf les installations inhabituelles. <tag>Suggests <item>C'est utilisé pour déclarer qu'un paquet peut être plus utile avec un ou plusieurs autres. En utilisant ce champ, on indique au système de paquet et à l'utilisateur que les paquets listés sont liés au paquet et peuvent peut-être augmenter son utilité, mais que l'installation du paquet sans eux est parfaitement concevable. <tt>dselect</> offrira les paquets suggérés à l'administrateur du système quand ils sélectionnent les paquets suggérés, mais par défaut, il n'installe pas les paquets suggérés. <tag>Pre-Depends <item>Ce champ ressemble à <tt>Depends</>, sauf qu'il force aussi <tt>dpkg</> à compléter l'installation des paquets nommés avant même de démarrer l'installation du paquet qui déclare les pré-dépendances. <tt>dselect</> vérifie les pré-dépendances quand il fait une installation, et essayer de trouver les paquets qui sont nécessairement installés avant et le fait dans le bon ordre. Cependant, ce processus est lent (car il nécessite des appels répétés à <tt>dpkg</>) et pénible (car il nécessite de deviner où se trouvent les fichiers appropriés). Pour ces raisons, et car ce champ impose des restrictions sur l'ordre dans lequel les paquets doivent être installés (ce qui peut-être difficile pour des installation à partir de média différent, par exemple). <tt>Pre-Depends</> devrait être utilisé avec modération, de préférence seulement pour les paquets dont la mise à jour prématuré ou l'installation pourrait entraver la capacité du système de continuer les mises à jour en cours. Quand le paquet déclarant qu'il a été configuré, une <tt>Pre- Dependency</> sera considérée satisfaite seulement si le paquet dépendant a bien été configuré, juste comme ci une <tt>Depends</> ordinaire avait été utilisé. Cependant, quand un paquet déclarant un pré-dépendance est installé, la pré-dépendance peut être satisfaite même si le ou les paquets d'appui sont seulement installés ou à moitié configurés, indiquant qu'ils ont été correctement installés à un moment dans la passé (et pas effacés ou partiellement effacés depuis). Dans ce cas, les deux versions précédemment configurées et en cours d'installation ou à moitié configurées doivent satisfaire n'importe quelle clause de version du champ <tt>Pre-Depends</>. </taglist> Quand on sélectionne le niveau de dépendance à utiliser, tu dois considéré l'impact des fonctionnalité du paquet d'appui sur le paquet déclarant la dépendance. Certains paquets sont constitués de composants de différents niveaux d'importance. De tel paquet devrait lister en utilisant <tt>Depends</>, le ou les paquets qui sont nécessaires par les composants les plus importants. Les autres composants exigés peuvent être mentionnés comme Suggestions ou Recommendations, en fonction de l'importance du composant. <sect1 id="relationpaquets-2-1">Les dépendances sur les librairies partagées Les champs de dépendance listés ci-dessus sont utilisés par les paquets qui ont besoin de librairies partagées pour déclarer les dépendances sur les paquets appropriés. Ces dépendances sont généralement déterminées automatiquement en utilisant <tt>dpkg-shlibdeps</> et insérées dans le fichier de contrôle du paquet en utilisant le mécanisme de substitutions de variables du fichier de contrôle; voir <ref id="paquetssources-2-3"> et <ref id="paquetssources-1">. <sect1 id="relationpaquets-2-2">Déconfiguration à cause d'effacement pendant les installations Si <tt>dpkg</> veux effacer un paquet à cause d'un conflit, comme décrit ci-dessus, mais en violation avec une dépendance de certains autres paquets sur le système, <tt>dpkg</> n'effacera généralement pas le paquet en conflit et s'arrêtera sur une erreur. Cependant, si l'option <tt>--auto-deconfigure (-B)</> est utilisée, <tt>dpkg</> déconfigurera automatiquement le paquet avec la dépendance problématique, afin que le paquet en conflit puisse être enlevé et le paquet à installer puisse être installé. Si <tt>dpkg</> est appelé pour installer des paquets (plutôt que juste les dépaqueter), il essayera de reconfigurer le paquet quand il aura dépaqueté tous ces arguments, dans l'espoir qu'un des autres paquets qu'il installe, satisfera la dépendance problématique. <tt>dselect</> fournit ces arguments à <tt>dpkg</> quand il l'appelle, afin de procéder aux installations facilement. <sect id="relationpaquets-3">Les paquets alternatifs - <tt>Conflicts</> et <tt>Replaces</> Quand un paquet déclare un conflit avec un autre, <tt>dpkg</> refusera de les installer sur le système en même temps. Si un paquet est installé, les autres doivent être enlevé d'abord - si le paquet en cours d'installation est marqué comme remplacement (voir <ref id="relationpaquets-5">) du paquet sur le système, ou si celui du système est marqué comme désélectionner, ou les deux paquets sont marqués <tt>Essential</>, alors <tt>dpkg</> enlèvera automatiquement le paquet qui provoque le conflit, autrement il arrête l'installation des nouveaux paquets par une erreur. <tt>dselect</> rend difficile la sélection des paquets en conflit, bien que l'utilisateur puisse l'annuler s'il le veut. S'ils ne sont pas annulés alors <tt>dselect</> sélectionnera un des paquets pour l'effacer, et l'utilisateur doit être sûr que c'est le bon. Dans le futur, <tt>dselect</> vérifiera la présence d'un champ <tt>Replaces</> pour décider quel paquet doit être installé et lequel enlevé. Un paquet ne provoquera pas de conflit, simplement car ses fichiers de configuration sont toujours installés; il doit être au moins à moitié installé. Une exception spéciale est faite pour les paquets qui déclare un conflit avec leur propre nom de paquet, ou avec un paquet virtuel qu'ils fournissent (voir ci-dessous); cela n'empêche pas leurs installations, et autorise un paquet d'être en conflit avec d'autres fournissant un remplacement pour lui. Tu peux utiliser ce dispositif quand tu veux que le paquet en question soit le seul paquet fournissant quelque chose. Une entrée <tt>Conflicts</> ne devrait presque jamais avoir une clause de version 'avant'. Ceci devait empêcher <tt>dpkg</> de mettre à jour ou d'installer le paquet qui déclare un tel conflit jusqu'à ce que la mise à jour ou l'effacement du paquet en conflit soient résolus. Cet aspect de l'ordre d'installation n'est pas géré par <tt>dselect</>, afin que l'utilisation de <tt>Conflicts</> provoque des problèmes pour les mises à jour et les installations. <sect id="relationpaquets-4">Les paquets virtuels - <tt>Provides</> Aussi bien que les noms de paquets concrets (réels), les champs de relations de paquet <tt>Depends, Recommends, Suggests</> et <tt>Conflicts</> peuvent mentionner des paquets virtuels. Un paquet virtuel est un paquet qui apparaît dans le champ <tt>Provides</> du fichier de contrôle d'un autre paquet. L'effet est comme ci le ou les paquets qui fournissent un nom particulier de paquet virtuel avaient été listés par nom partout le nom du paquet virtuel apparaît. Si il y a deux paquets, un réel et un virtuel du même nom alors la dépendance peut être satisfaite (or le conflit provoqué par) soit par le paquet réel ou n'importe quels paquets virtuels que la fournit. Par exemple, nous avons: <example> Package: vm Depends: emacs </example> Et quelqu'un d'autre met à jour un paquet xemacs, ils peuvent dire: <example> Package: xemacs Provides: emacs </example> Et tout fonctionnera entre temps (jusqu'à ce qu'un nom de paquet purement virtuel est décidé et les paquets <tt>emacs</> et <tt>vm</> soient modifiés pour l'utiliser). Si une dépendance ou un conflit a un numéro de version attaché alors seuls les paquets réels seront considérés pour voir si la relation est satisfaite (ou la prohibition violée, pour un conflit) - on supposera qu'un paquet réel qui fournit un paquet virtuel n'est pas la bonne version. Ainsi, un champ <tt>Provides</> ne doit pas contenir de numéros de version, et le numéro de version d'un paquet concret qui fournit un paquet virtuel particulier ne le regardera pas quand on considère une dépendance ou un conflit avec le nom du paquet virtuel. Si tu veux spécifier quel paquet d'un ensemble de paquets réels devrait être celui satisfait par défaut une dépendance particulière sur un paquet virtuel, tu devrais lister le paquet réel comme alternatif avant le paquet virtuel. <sect id="relationpaquets-5"><tt>Replaces</> - écraser les fichiers et remplacer les paquets Le champ <tt>Replaces</> du fichier de contrôle a deux buts qui entre en jeu dans des situations différentes. Les paquets virtuels (voir <ref id="relationpaquets-4">) ne sont pas considérés quand on regarde le champ <tt>Replaces</> - les paquets déclarés comme étant remplacés doivent être mentionnés par leurs noms réels. <sect1 id="relationpaquets-5-1">Ecraser les fichiers dans les autres paquets. Tout d'abord, comme mentionné avant, c'est généralement une erreur pour un paquet de contenir des fichiers qui sont sur le système dans un autre paquet, bien que couramment l'option <tt>--force-overwrite</> soit mise par défaut, déclassant l'erreur en avertissement. Si le paquet qui écrase déclare qu'il remplace l'ancien contenant le fichier qui doit être écrasé alors <tt>dpkg</> le traitera, et remplacera le fichier de l'ancien paquet par le nouveau. Le fichier ne sera plus listé comme faisant partie de l'ancien paquet. Si un paquet est complètement remplacé de cette façon, afin que <tt>dpkg</> ne sait pas quels fichiers il contient, il est considéré comme ayant disparu. Il sera marqué comme non sélectionné sur le système (sélectionné pour l'effacement) et non installé. tous les détails des conffiles notés dans le paquet seront ignorés, comme ils seront pris par le paquet qui le remplace. Le script <tt>postrm</> du paquet sera exécuté pour permettre au paquet de faire le nettoyage final nécessaire. Voir <ref id="scriptmaintenance-2">. Dans le futur, <tt>dpkg</> écartera les fichiers qui écrasent ceux d'un autre paquet qui déclare qu'il remplace celui qui est en cours d'installation (afin de pouvoir installer une version plus ancienne d'un paquet sans problèmes). L'usage de <tt>Replaces</> prend seulement effet quand deux paquets sont au moins partiellement sur le système à la fois, cela peut seulement se produire s'ils ne sont pas en conflits, ou si le conflit a été annulé. <sect1 id="relationpaquets-5-2">Remplacer tous les paquets, forcer leur effacement Deuxièmement, <tt>Replaces</> permet à <tt>dpkg</> et <tt>dselect</> de résoudre quel paquet doit être enlevé quand il y a un conflit - voir <ref id="relationpaquets-3">. Cet usage prend seulement effet quand deux paquets sont en conflit, afin que les deux effets n'interfèrent pas l'un avec l'autre. <sect id="relationpaquets-6">Options pour satisfaire les dépendances - tri Le tri est significatif dans les champs de dépendance. Généralement, dselect suggérera à l'utilisateur qu'ils sélectionnent le paquet avec la classe la plus 'fondamental' (il préférera les paquets de Base plutôt que les paquets optionnels), ou le paquet qu'ils veulent le plus sélectionner, dans un certain sens. En l'absence d'autres informations, <tt>dselect</> offrira une sélection par défaut des premiers paquets nommés de la liste des alternatives. Cependant, il n'y a aucun moyen de spécifier l'ordre de plusieurs paquets qui fournissent tous la même chose quand cette chose est listée comme dépendance. Donc, une dépendance sur un paquet virtuel devrait contenir un nom de paquet concret comme première alternative par défaut. Par exemple, considérons l'ensemble de paquets suivant: <example> Package: glibcdoc Recommends: info-browser Package: info Provides: info-browser Package emacs Provides: info-browser </example> Si <tt>emacs</> et <tt>info</> ont tous les deux la même priorité alors le choix <tt>dselect</> est essentiellement aléatoire. Le mieux serait: <example> Package: glibcdoc Recommends: info | info-browser </example> afin que <tt>dselect</> sélectionne l'info-browser. ********************************************************** <chapt id="fichiersconf">Manipulation des fichiers de configuration <prgn/dpkg/ peut faire une certaine quantité de manipulation automatique sur les fichiers de configuration de paquet. Pour que ce mécanisme soit adéquate, cela dépend d'un certain nombre de facteurs, mais fondamentalement, il y a deux approches pour n'importe quel fichier de configuration particulier. La méthode facile est de transposer un meilleur effort de configuration dans le paquet et utiliser le mécanisme de fichier de configuration de <prgn/dpkg/ pour manipuler les mises à jour. Il est peu probable que l'utilisateur veuille éditer le fichier, mais il faut que cela soit possible sans perdre leur modification, et un nouveau paquet avec une version modifiée du fichier est seulement mis à jour rarement, c'est la meilleure approche. La méthode dure est de construire le fichier de configuration à partir du script <tt>postinst</>, et de prendre la responsabilité de résoudre automatiquement les erreurs des versions précédentes du paquet. Ceci est justifié si le fichier est nécessairement différent sur chaque système. <sect id="fichiersconf-1">Manipulation automatique des fichiers de configuration par <tt>dpkg</> Un paquet peut contenir un fichier de zone de contrôle appelé <prgn/conffiles/. Ce fichier doit être une liste de noms de fichier de configuration nécessitant une manipulation automatique, séparée par un retour chariot. Les noms de fichiers doivent avoir des noms absolus, et les fichiers référencés doivent réellement exister dans le paquet. Quand un paquet est mis à jour, <prgn/dpkg/ traitera les fichiers de configuration pendant l'étape de configuration, juste avant d'exécuter le script <tt>postinst</> du paquet. Pour chaque fichier, il vérifie si la version du fichier inclus dans le paquet est la même que celle qui était insérée dans la dernière version du paquet (celui à partir duquel on fait la mise à jour). <prgn/dpkg/ compare aussi les versions courantes installées sur le système avec celle transportée avec la dernière version. Si ni l'utilisateur, ni le mainteneur du paquet n'ont changé le fichier, il est laissé tel quel. Sinon si l'un ou l'autre a changé sa version, alors les nouvelles versions sont prises en compte, c'est à dire si l'utilisateur édite son fichier, mais le mainteneur n'a pas amené une version différente, les modifications de l'utilisateur demeurent (silencieusement), mais si le mainteneur amène une nouvelle version et l'utilisateur ne l'a pas édité, la nouvelle version sera installée (avec un message d'avertissement). Si les deux ont changé leurs versions, l'utilisateur est averti du problème et doit résoudre les différences lui-même. La comparaison est faite en calculant le MD5 des fichiers et en stockant ce MD5 comme s'il était inclus dans la plus récente version du paquet. Quand un paquet est installé pour la première fois, <prgn/dpkg/ installera le fichier qui l'accompagne, à moins que cela pourrait signifier un écrasement d'un fichier existant sur le système de fichier. Cependant, notons que <prgn/dpkg/ ne remplacera pas un fichier de configuration qui a été enlevé par l'utilisateur (ou par un script). Cela est nécessaire parce que avec certains programmes, un fichier manquant produit un effet dur ou impossible à réaliser d'une autre manière, un fichier manquant ne sera pas remplacé si l'utilisateur l'a décidé ainsi. Notons qu'un paquet ne doit pas modifier un fichier de configuration manipulé par <prgn/dpkg/ dans son script de maintenance. Faire cela amènera <prgn/dpkg/ à donner à l'utilisateur, des options confuses ou dangereuse pour la mise à jour des fichiers de configuration quand le paquet est révisé. <sect id="fichiersconf-2">Manipulation des scripts améliorés de configuration de maintenance Pour les fichiers qui contiennent des informations spécifiques telles que le nom de l'hôte et les détails réseau et ainsi de suite, il est préférable de créer le fichier dans le script <tt>postinst</> du paquet. Ceci impliquera typiquement, l'examen de l'état du reste du système pour déterminer les valeurs et autres informations, et peut aussi impliquer une saisie par l'utilisateur des informations qui n'ont pas pu être obtenues autrement. Quand on utilise cette méthode, il y a un nombre important de problèmes à considérer: Si tu découvres une erreur dans un programme qui génère le fichier de configuration, ou si le format d'un fichier change d'une version à la suivante, tu devras modifier le script <tt>postinst</> pour le corriger, habituellement cela veut dire, éditer le fichier de configuration installé et enlever le problème ou changer la syntaxe. Tu devras faire ça avec attention étant donné que l'utilisateur peut avoir changé le fichier, peut être pour fixer le problème que ton script est en train de traiter, tu devras détecter ces situations et les traiter correctement. Si tel est ton choix, c'est alors probablement une bonne idée de rendre le programme qui génère le fichier de configuration en un programme séparé dans <tt>/usr/sbin</>, appelé par convention paquet</><tt>config</> et l'exécuter si approprié, à partir du script de post-installation. Le programme paquet</><tt>config</> ne doit pas écraser une configuration existante - si son mode opératoire est tourné vers le positionnement d'un paquet pour la première fois (plutôt que n'importe quelle reconfiguration arbitraire ultérieure), tu dois vérifier si la configuration existe déjà, et utiliser l'option <tt>--force</> pour l'écraser. ********************************************************* <chapt id="versionsalt">Les versions alternatives d'une interface - <tt>update- alternatives</> Quand plusieurs paquets fournissent tous des versions différentes du même programme ou fichier, il est utile que le système en sélectionne un par défaut, mais d'autoriser l'administrateur système de le changer et d'avoir leurs décisions respectées. Par exemple, il y a plusieurs versions de l'éditeur <tt>vi</>, et il n'y a aucune manière de les empêcher tous de s'installer à la fois, chacun sous leur propre nom (<tt>nvi, vim</> etc). Néanmoins, il est souhaitable d'avoir le nom <tt>vi</> qui se réfère à quelque chose, au moins par défaut. Si tous les paquets impliqués coopèrent, ceci peut être fait par <tt>update-alternatives</>. Chaque paquet fournit sa propre version sous son propre nom, et appelle <tt>update-alternatives</> dans script <tt>postinst</> pour enregistrer sa version (et de nouveau dans son <tt>prerm</> pour l'enlever). Voir le manuel en page <manref name="update-alternatives" section="8"> pour les détails. Si <tt>update-alternatives</> ne semble pas approprié, tu peux essayer d'utiliser les diversions à la place. *********************************************************************** <chapt id="deviation">Déviation - écraser une version de paquet d'un fichier Il est possible d'éviter à <prgn/dpkg/ d'écraser un fichier quand il réinstalle le paquet auquel il appartient, et de mettre le fichier du paquet autre part. Cela peut être utilisé localement pour écraser une version de paquet d'un fichier, ou par un paquet pour écraser une autre version (ou pour fournir un lien pour elle). Avant de décider de l'utilisation d'une déviation, lire <ref id="versionsalt">, pour savoir si tu veux vraiment une déviation plutôt que plusieurs versions alternatives d'un programme. Il y a une liste de déviation qui est lue par <prgn/dpkg/ et mise à jour par un programme spécial <prgn/dpkg-divert/. Voir <manref name="dpkg-divert" section="8"> pour plus de renseignements sur ses arguments. Quand un paquet souhaite différencier un fichier d'un autre, il doit appelé <prgn/dpkg-divert/ dans sa pré-installation pour ajouter la déviation et renommer le fichier existant. Par exemple, supposons qu'un paquet <prgn/smailwrapper/ souhaite installer un lien sur <prgn>/usr/sbin/smail</>: <example> if [ install = "$1" ]; then dpkg-divert --package smailwrapper --add --rename \ --divert /usr/sbin/smail.real /usr/sbin/smail fi </example> Le test de <tt>$1</> est nécessaire afin que le script n'essaye pas d'ajouter encore la déviation quand <prgn/smailwrapper/ est mis à jour. L'option <tt>--package smailwrapper</> assure que la copie de <tt>smailwrapper</> du répertoire <prgn>/usr/sbin/smail</> peut contourner la déviation et s'installer comme la vraie version. Le <tt>postrm</> fait l'inverse: <example> if [ remove = "$1" ]; then dpkg-divert --package smailwrapper --remove --rename \ --divert /usr/sbin/smail.real /usr/sbin/smail fi </example> N'essaie pas dévier un fichier qui est vital pour le système d'exploitation. Quand on utilise <tt>dpkg</>, il y a un moment, après que le fichier ait été dévié, mais avant que <tt>dpkg</> ait installé la nouvelle version, où le fichier n'existe pas. *********************************************************** <chapt id="libpartages">Les librairies partagées Les paquets contenant les librairies partagées doivent être construits avec un peu de soin pour être sûr que les librairies partagées soient toujours disponibles. C'est spécialement important pour les paquets dont les librairies sont vitalement important, tel que la libc. Tout d'abord, ton paquet devrait installer les librairies partagés sous leurs noms normaux. Par exemple, le paquet <tt>libgdbm1</> devrait installer <tt>libgdbm.so.1.7.3</> comme <tt>/usr/lib/libgdbm.so.1.7.3</>. Les fichiers ne devraient pas être renommés ou liés par les scripts prerm et postrm; <tt>dpkg</> s'occupera de renommer les choses doucement sans troubler les programmes exécutés et essayer d'interférer avec lui mène aux problèmes. Ensuite, ton paquet doit inclure le lien symbolique que <tt>ldconfig</> doit créer pour les librairies partagées. Par exemple, le paquet <tt>libgdbm1</> doit inclure un lien symbolique de <tt>/usr/lib/libgdbm.so.1.7.3</> vers <tt>libgdbm.so.1.7.3</>. Ceci est nécessaire pour que <tt>ld.so</> trouve la librairie pendant que <tt>dpkg</> l'installe et <tt>ldconfig</> est exécuté dans le script <tt>postinst</>. De plus, et c'est important</>, la librairie doit être placée avant le lien qui pointe sur elle dans le fichier <tt>.deb</>. C'est afin que le temps que <tt>dpkg</> installe le lien symbolique (en écrasant le lien précédent pointant sur une version plus ancienne de la librairie), la nouvelle librairie soit déjà en place. Pour l'instant, la seule façon d'assurer que l'ordre est respecté est d'installer la librairie dans le répertoire <tt>debian/tmp/.../lib</> approprié avant de créer le lien symbolique, en mettant les commandes dans <tt>debian/rules</> dans l'ordre approprié. Troisièmement, le paquet de développement devrait contenir un lien symbolique pour la librairie partagée sans un numéro de version. Par exemple, le paquet <tt>libgdbm1-dev</> devrait inclure un lien symbolique de <tt>/usr/lib/libgdbm.so</> vers <tt>libgdbm.so.1.7.3</>. Ce lien symbolique est nécessaire pour <tt>ld</> quand il compile les paquets, il cherchera seulement <tt>libgdbm.so</> et <tt>libgdbm.a</> pour compiler dynamiquement ou statiquement, respectivement. Si tu fait ce qu'il y a au dessus, ton paquet n'a pas besoin d'appeler <tt>ldconfig</> dans ses scripts de maintenance. C'est spécialement important de ne pas appeler <tt>ldconfig</> dans les scripts postrm ou preinst dans le cas où le paquet est mis à jour voir <ref id="scriptmaintenance-3">), étant donné que <tt>ldconfig</> verra les noms temporaires que <tt>dpkg</> utilise pour les fichiers pendant leur installation et fera les liens des librairies partagées pointer sur eux, juste avant que <tt>dpkg</> continue l'installation et enlève les liens !!! <sect id="libpartages-1">Le format du fichier <tt>shlibs</> Ce fichier est utilisé par <tt>dpkg-shlibdeps</> et est nécessaire quand ton paquet fourni des librairies partagées. Chaque ligne est de la forme: <example> nom-librairie version-ou-ainsinommé dépendances ... </example> nom-librairie</> est le nom de la librairie partagée, par exemple <tt>libc5</>. version-ou-ainsinommé</> est le nom de la librairie - c'est à dire la chose qui doit coller exactement pour que la librairie soit reconnue par <tt>ld.so</>. Généralement, c'est le numéro majeur de la version de la librairie. dépendances</> a la même syntaxe que le champ dépendance dans le fichier de contrôle des paquets binaires. Il devrait donner les détails sur quels paquets sont nécessaires pour satisfaire une construction binaire par rapport à la version de librairie contenue dans le paquet. Voir <ref id="relationpaquets-1">. Par exemple, si le paquet <tt>foo</> contient <tt>libfoo.so.1.2.3</> ou le nom de la librairie est <tt>libfoo.so.1</>, et la première version du paquet qui contient les numéros mineurs d'au moins <tt>2.3</> était 1.2.3-1</>, alors le shlibs</> du paquet peut dire: <example> libfoo 1 foo (>= 1.2.3-1) </example> La dépendance de version spécifique est d'éviter les avertissements de <tt>ld.so</> sur l'utilisation des anciennes librairies partagées avec des nouveaux binaires. <sect id="libpartages-2">Davantage d'informations techniques sur <tt>shlibs</> <sect1 id="libpartages-2-1">Que sont les fichiers <tt>shlibs</>? Le fichier <tt>debian/shlibs</> fournit une façon de vérifier les dépendances des librairies partagées des paquets binaires. Ils sont utilisés par les mainteneurs de paquet pour rendre leur vie plus facile. Les autres fichiers <tt>shlibs</> qui existent sur un système Debian sont: <list> <item><tt>/etc/dpkg/shlibs.default</> <item><tt>/etc/dpkg/shlibs.override</> <item><tt>/var/lib/dpkg/info/*.shlibs</> <item><tt>debian/shlibs.local</> </list> Ces fichiers sont utilisés par <tt>dpkg-shlibdeps</> à la création d'un paquet binaire. <sect1 id="libpartages-2-2">Comment fonctionne <tt>dpkg-shlibdeps</>? <tt>dpkg-shlibdeps</> appelle <tt>ldd</> pour déterminer les librairies partagées utilisées par les binaires compilés passés en paramètre sur sa ligne de commande. Pour chaque librairie partagée, <tt>dpkg-shlibdeps</> a besoin de savoir <list> <item>le paquet contenant la librairie, et <item>le numéro de version de la librairie. </list> Il scrute le fichiers suivants dans l'ordre: <enumlist> <item><tt>debian/shlibs.local</> <item><tt>/etc/dpkg/shlibs.override</> <item><tt>/var/lib/dpkg/info/*.shlibs</> <item><tt>/etc/dpkg/shlibs.default</> </enumlist> <sect1 id="libpartages-2-3">Qui maintient les nombreux fichiers <tt>shlibs</>? <list> <item><tt>/etc/dpkg/shlibs.default</> - le mainteneur de dpkg <item><tt>/var/lib/dpkg/info/</>paquet</><tt>.shlibs</> - le mainteneur de chaque paquet <item><tt>/etc/dpkg/shlibs.override</> - l'administrateur système local <item><tt>debian/shlibs.local</> - le mainteneur du paquet </list> Le fichier <tt>shlibs.default</> est géré par <tt>dpkg</>. Les entrées dans <tt>shlibs.default</> qui sont fournies par <tt>dpkg</>, sont juste là pour fixer les choses le temps que les paquets de librairie partagée ont toutes leurs fichiers <tt>shlibs</>. <sect1 id="libpartages-2-4">Comment utiliser <tt>dpkg-shlibdeps</> et les fichiers <tt>shlibs</>? <sect2 id="libpartages-2-4-1">Si ton paquet ne fournit pas de librairie partagée Place un appel à <tt>dpkg-shlibs</> dans ton fichier <tt>debian/rules</>. Si ton paquet contient seulement des binaires (aucun scripts) utilise: <example> dpkg-shlibdeps debian/tmp/usr/{bin,sbin}/* </example> Si <tt>dpkg-shlibdeps</> ne se plaint pas, c'est bon. Sinon, tu dois créer ton propre fichier <tt>debian/shlibs.local</>. <sect2 id="libpartages-2-4-2">Si ton paquet fournit une librairie partagée Crée un fichier <tt>debian/shlibs</> et laisse <tt>debian/rules</> l'installer dans la zone de contrôle: <example> install -m644 debian/shlibs debian/tmp/DEBIAN </example> Si ton paquet contient des binaires supplémentaires voir ci-dessus. <sect1 id="libpartages-2-5">Comment écrire <tt>debian/shlibs.local</>? Ce fichier sert seulement à fixer temporairement</> si tes binaires ne dépendent pas d'une librairie qui ne fournit pas déjà son propre fichier <tt>/var/lib/dpkg/*.shlibs</>. Supposons que tu crées un paquet binaire <tt>foo</>. Ta sortie doit ressembler à cela pendant la construction du paquet. <example> $ ldd foo libbar.so.1 => /usr/X11R6/lib/libbar.so.1.0 libc.so.5 => /lib/libc.so.5.2.18 libX11.so.6 => /usr/X11R6/lib/libX11.so.6.0 </example> Et quand tu exécutes <tt>dpkg-shlibdeps</> <example> $ dpkg-shlibdeps -o foo dpkg-shlibdeps: warning unable to find dependency information for shared library libbar (soname 1, path /usr/X11R6/lib/libbar.so.1.0, dependency field Depends) shlibs:Depends=elf-x11r6lib, libc5 (>= 5.2.18) </example> Le binaire <tt>foo</> dépend de la librairie partagée <tt>libbar</> , mais aucun paquet ne semblent fournir un fichier <tt>*.shlibs</> dans <tt>/var/lib/dpkg/info/</>. Déterminons le paquet responsable: <example> $ dpkg -S /usr/X11R6/lib/libbar.so.1.0 bar1: /usr/X11R6/lib/libbar.so.1.0 $ dpkg -s bar1 | grep Version Version: 1.0-1 </example> Ce qui nous indique que le paquet <tt>bar1</>, version 1.0-1 est celui qu'on utilise. Maintenant nous pouvons créer notre propre <tt>debian/shlibs.local</> pour fixer temporairement, les problèmes ci- dessus. Inclus la ligne suivante dans ton fichier <tt>debian/shlibs.local</>. <example> libbar1 bar1 (>= 1.0-1) </example> Maintenant ton paquet construit doit fonctionner. Dès que le mainteneur de <tt>libbar1</> fournir un fichier <tt>shlibs</>, tu peux enlever ton fichier <tt>debian/shlibs.local</>. ***************************************************** <chapt id="confinit">Configuration d'<tt>init</> <sect id="confinit-1">Introduction à la structure de <tt>init.d</> Le répertoire <prgn>/etc/init.d</> contient les scripts démarrés par <prgn/init/ quand l'état du niveau d'exécution est changé (voir <manref name="init" section="8">). Ces scripts sont référencés par des liens symboliques dans les répertoires <tt>/etc/rc</>n</><tt>.d</>. Quand on change le niveau d'exécution, <prgn/init/ recherche dans le répertoire <tt>/etc/rc</>n</><tt>.d</> le script à exécuter, où n</> est le niveau d'exécution à atteindre. Le nom des liens ont tous la forme <tt>S</>mmscript</> ou <tt>K</>mmscript</> où mm</> correspond à 2 chiffres et script</> est le nom du script (il doit être le même que le nom du script réel dans <tt>/etc/init.d</>). Quand <prgn/init/ change le niveau d'exécution, d'abord les cibles des liens dont les noms commencent par <tt>K</> sont exécutées, chacune avec un seul argument <tt>stop</>, suivi par les scripts préfixés par un <tt>S</>, chacun avec l'argument <tt>start</>. Les liens <tt>K</> sont responsables de l'arrêt des services et les liens <tt>S</> du démarrage des services du nouveau niveau d'exécution. Par exemple, si nous passons du niveau 2 au niveau 3, <prgn/init/ exécutera d'abord tous les scripts préfixés par <tt>K</> qu'il trouve dans <tt>/etc/rc3.d</> et ensuite tous les scripts préfixés par <tt>S</>. Les liens commençant par <tt>K</> amèneront le fichier référencé à s'exécuter avec l'argument <tt>stop</>, et les liens <tt>S</> avec un argument <tt>start</>. Les 2 chiffres mm</> sont utilisés pour décider dans quel ordre démarrer et arrêter les choses. Les liens exécutent leurs scripts dans un ordre croissant. Par exemple les scripts <tt>K20</> seront exécutés avant les scripts <tt>K30</>. Cela est utilisé quand certains services doivent démarrer avant d'autres. Par exemple, le serveur de nom <prgn/bind/ doit être démarré avant le serveur de news <prgn/inn/ afin qu'<prgn/inn/ puisse positionner ses listes d'accès. Dans ce cas, le script qui démarre <prgn/bind/ doit avoir un plus petit numéro que le script qui lance <prgn/inn/ pour démarrer d'abord: <example> /etc/rc2.d/S17bind /etc/rc2.d/S70inn </example> <sect id="confinit-2">Ecrire des scripts <tt>init.d</> Les paquets peuvent et doivent placer les scripts dans <tt>/etc/init.d</> pour démarrer ou arrêter les services au démarrage ou pendant un changement de niveau d'exécution. Ces scripts doivent être nommées <tt>/etc/init.d/</>package</>, et ils doivent accepter un argument: <tt>start</> signifiant de démarrer le service, ou <tt>stop</> pour arrêter le service. Facultativement, ils peuvent supporter l'argument <tt>reload</> qui provoque le rechargement de la configuration. Les scripts doivent s'assurer qu'ils se comporteront judicieusement, s'ils sont invoqués avec l'option <tt>start</> quand le service est déjà en action, ou <tt>stop</> s'il ne l'est pas, et qu'ils ne tuent pas fortuitement les process des utilisateurs. La meilleure façon de réaliser cela est d'utiliser habituellement le programme <prgn/start-stop-deamon/. Ces scripts ne doivent pas échouer de façon obscure quand les fichiers de configuration persistent alors que le paquet a été enlevé, par défaut <prgn/dpkg/ laisse les fichiers de configuration dans le système après que le paquet ait été enlevé. C'est seulement quand il est exécuté avec l'option <tt>--purge</>, que <prgn/dpkg/ enlèvera les fichiers de configuration. Cependant, tu dois inclure une instruction de test au début du script: <example> test -f programme-exécuté-dans-le-script</> || exit 0 </example> <sect id="confinit-3">Gestion des liens <tt>rc</>n</><tt>.d</> - <tt>update-rc.d</> Un programme <prgn/update-rc.d/ est fourni pour faciliter la maintenance des paquets dans l'orchestration de la création et de la destruction des liens symboliques de <tt>/etc/rc</>n</><tt>.d</> à partir de leurs scripts <tt>postinst</> et <tt>postrm</>. Tu dois utiliser ce script pour réaliser les changements dans <tt>/etc/rc</>n</><tt>.d</> et jamais inclure n'importe quels liens symboliques <tt>/etc/rc</>n</><tt>.d</> dans l'archive réel. Par défaut, <prgn/update-rc.d/ démarrera les services dans chacun des niveaux d'état d'exécution multi-utilisateur (2, 3, 4, et 5) et les arrêtent dans le niveau <prgn/halt/ (0), niveau mono-utilisateur (1), et le niveau <prgn/reboot/ (6). L'administrateur système a l'opportunité de personnaliser les niveaux d'exécution en ajoutant, en déplaçant, ou en enlevant simplement les liens symboliques dans <tt>/etc/rc</>n</><tt>.d</>. Pour obtenir le comportement par défaut de ton paquet, mets dans ton script <tt>postinst</>: <example> update-rc.d package</> default >/dev/null </example> et dans ton script <tt>postrm</>: <example> if [ purge = "$1" ]; then update-rc.d package</> remove >/dev/nul fi </example> Ceci utilisera un numéro de séquence par défaut à 20. Si on ne tient pas compte de quand ou dans quel ordre le script est exécuté, utilise le numéro par défaut. Sinon, tu dois demander un numéro au mainteneur du paquet <prgn/sysvinit/ ou dans la mailing list <tt>debian-devel</>, ils t'aideront à en choisir un. Pour plus d'information sur l'utilisation d'<prgn/update-rc.d/, consulte la page de manuel <manref name="update-rc.d" section="8">. <sect id="confinit-4">Initialisation du démarrage - <tt>rc.boot</> Il y a un autre répertoire <tt>/etc/rc.boot</> qui contient les scripts qui sont exécutés une fois par démarrage. Ce dispositif est fournie pour l'initialisation de matériels périphériques, nettoyage de fichiers, et ainsi de suite. Par exemple, le paquet <prgn/kbd/ fournit un script pour l'initialisation de la configuration clavier, la fonte et le mode de la console. Les fichiers dans <tt>/etc/rc.boot</> ne doivent pas être liés dans <tt>/etc/init.d</>. Ceux sont des scripts à part entière. <tt>rc.boot</> ne doit pas être utilisé pour démarrer des processus à but général, et activités similaires. Ceci doit être fait en utilisant la structure <tt>rc</>n</><tt>.d</>, ci-dessus, afin que les services puissent être démarrés et arrêtés proprement quand le niveau d'exécution change ou quand la machine doit être éteinte ou rebootée. <sect id="confinit-5">Remarques Ne pas inclure les liens symboliques de <tt>/etc/rc</>n</><tt>.d/*</> dans l'archive <tt>.deb</> du système de fichier! Cela amènera des problèmes! Tu dois les créer avec <prgn/update-rc.d/, comme ci-dessus. Ne pas include les liens symboliques de <tt>/etc/rc</>n</><tt>.d/*</> dans la liste de fichiers de configuration de <prgn/dpkg/! Cela provoquera des erreurs! Il faut cependant inclure les scripts <tt>/etc/init.d</> dans les fichiers de configuration. <sect id="confinit-6">Exemple Le paquet DNS <prgn/bind/ (serveur de nom) veut être sûr que le serveur de nom soit démarré dans les niveaux d'exécution multi-utilisateurs, et proprement arrêté avec le système. Il met un script dans <tt>/etc/init.d</> nommé <prgn/bind/. Comme indiqué ci-dessous, le script interprète l'argument <tt>reload</>, pour envoyer le signal <tt>HUP</> au serveur de nom (provoquant le rechargement de sa configuration). De cette façon, l'utilisateur peut taper <tt>/etc/init.d/bind reload</> pour recharger la configuration du serveur de nom. <example> #!/bin/sh # Original version par Robert Leslie <rob@mars.org>, edited by iwj test -x /usr/sbin/named || exit 0 case "$1" in start) test- f /etc/named.boot -a -f /var/name/boot.options || exit 0 start-stop-deamon --start --verbose --exec /usr/sbin/named ;; stop) start-stop-deamon --stop --verbose \ --pidfile /var/run/named.pid --exec /usr/sbin/named ;; reload) start-stop-deamon --stop --signal 1 --verbose \ --pidfile /var/run/named.pid --exec /usr/sbin/named ;; *) echo "Usage: /etc/init.d/bin {start|stop|reload}" >&2 exit 1 ;; esac exit 0 </example> Un autre exemple, sur lequel les scripts de <tt>/etc/init.d</> peuvent se baser, se trouve dans <tt>/etc/init.d/skeleton</>. Si ce paquet se contente de la configuration par défaut donné par <prgn/update-rc.d/, c'est à dire un numéro d'ordre égal à 20 et mise en oeuvre dans tous les niveaux d'exécution, il est possible d'écrire dans le script <tt>postinst</>: <example> update-rc.d bind default >/dev/null </example> Et dans son script <tt>postrm</>, la suppression du lien quand le paquet est détruit: <example> if [ purge = "$1" ]; then update-rc.d acct remove >/dev/null fi </example> ************************************************ <chapt id="intdselect">Interface dselect pour ses méthodes d'installation <tt>dselect</> appelle les scripts à partir des ses méthodes d'installation quand il a vraiment besoin d'accéder aux données de la distribution. Le programme noyau <tt>dselect</> lui-même appelle juste ces scripts et fournit le paquet et les interfaces de sélection des méthodes d'accès. Les méthodes d'installation sont responsables de l'appel approprié de <tt>dpkg</>. Chaque méthode d'installation a trois scripts: <list> <item>Positionner les paramètres d'installation (Setup) <item>Mettre à jour la liste des paquets disponibles (Upgrade) <item>installer (Install) </list> <tt>dselect</> cherche les méthodes dans les répertoires <tt>/usr/lib/dpkg/methods</> et <tt>/usr/local/lib/dpkg/methods</>. <sect id="intdselect-1">Les fonctions des scripts de méthode Le script setup est exécuté juste après que l'utilisateur a choisi une méthode d'installation. Il doit demander à l'utilisateur les paramètres comme le site NFS à monter ou FTP, le répertoire à utiliser, ou le répertoire ou le système de fichiers où les fichiers <tt>.deb</> peuvent être trouvés, ou le lecteur de bande, le lecteur de disquette d'install. Il devrait stocker la réponse sous <tt>/var/lib/dpkg/methods</> - voir ci-dessous. Si aucune liste de paquets n'est disponible, il devrait proposer peut-être la scrutation des paquets disponibles. Le script upgrade devrait obtenir une liste des paquets disponibles si possible, et démarrer <tt>dpkg --update-avail, dpkg --merge-avail</> et/ou <tt>dpkg --forget-old-unavail</> pour la charger dans la base de données des paquets disponibles de <tt>dpkg</> et de <tt>dselect</>. Si aucune liste de paquets n'est disponible et si on a proposé à l'utilisateur et qu'il a accepté l'option de scruter les fichiers réels disponibles, alors la scrutation doit être faite ici, en utilisant <tt>dpkg --record-avail</>. Le script install doit donner tous les fichiers <tt>.deb</> disponibles à <tt>dpkg -iGOEB</> (ce qui est équivalent à <tt>dpkg --install -- refuse-downgrade --selected-only --skip-same-version --auto- deconfigure</>). L'option <tt>-R</> (<tt>--recursive</>) pour traverser tous les sous-répertoires peut être utile ici. Si un de ces scripts a besoin d'afficher un message à l'utilisateur, il doit attendre que l'utilisateur tape 'return' avant de sortir afin que <tt>dselect</> ne rafraîchisse pas immédiatement l'écran. Si un script de méthode réussi (retourne un statut de sortie à zéro) <tt>dselect</> retournera immédiatement au menu principal, avec l'option suivante soulignée prêt pour être sélectionnée par l'utilisateur. S'il échoue, <tt>dselect</> affichera un message et attendra que l'utilisateur tape 'return'. <sect id="intdselect-2">Emplacement et arguments des scripts de méthode Un ensemble de scripts (aussi connu comme un groupe) peut fournir plusieurs méthodes dans le menu principal avec différent comportement. Par exemple, il peut y avoir un groupe pour récupérer les paquets par FTP qui peut fournir les méthodes dans le menu principal pour l'installation directe à partir d'un des sites miroirs Debian aussi bien que l'installation à partir d'un site spécifique à l'utilisateur. Chaque groupe de méthodes implantées par le même ensemble de scripts doit avoir un sous-répertoire <tt>/usr/lib/dpkg/methods</>/groupe</> ou <tt>/usr/local/lib/dpkg/methods</>/groupe</>, contenant: <taglist> <tag>names <item>une liste des méthodes visibles par l'utilisateur fournies par ces scripts. <tag>setup <tag>update <tag>install <item>les programmes exécutables, les scripts eux-mêmes. <tag>des.option</> <item>fichier de description </taglist> <tt>names</> sera formaté comme une liste de ligne, chacune contenant: <example> sequence méthode résumé </example> sequence</> est un nombre sur 2 chiffres qui sera utilisé comme pour les préfixes de <tt>rc.d</> pour contrôler l'ordre dans le menu principal. Dans le doute, utilise 50. méthode</> est un nom qui est affiché par <tt>dselect</> comme nom de la méthode et qui sera passé à <tt>setup, update</> et <tt>unpack</> comme premier argument. résumé</> est la brève chaîne de caractères de description pour le menu de <tt>dselect</>. Chacun de ces trois scripts prend les mêmes trois arguments: vardir, group</> et method</>. vardir</> est le répertoire de base pour stocker l'état de <tt>dpkg</> et de <tt>dselect</>, généralement <tt>/var/lib/dpkg</>; ceci est passé afin que l'option <tt>--admindir</> de <tt>dselect</> soit honorée. Chaque option peut avoir une description étendue dans <tt>desc.</>option</>. Celui-ci doit être formaté comme la partie description étendue comme une entrée du champ <tt>Description</> décalée d'un caractère vers la gauche</>. vardir</>/<tt>methods</> existera, et un groupe de méthodes peut utiliser un répertoire vardir</>/<tt>methods</>/group</> pour stocker ses états. Le nom du groupe et le nom des méthodes doivent suivre les règles des identificateurs C. </book>