Guide du nouveau responsable Debian

Ce document peut être utilisé selon les termes de la Licence publique générale de GNU version 2 ou suivante.

Ce document a été créé avec ces deux documents comme exemple :

Ce document essaye de décrire à l'utilisateur Debian courant (et au développeur en devenir) la construction d'un paquet Debian. Il utilise un langage assez courant, et est complété avec des exemples. Il y a un vieux proverbe romain, Longum iter est per preaecepta, breve et efficax per exempla! (C'est long par la règle, court et efficace par l'exemple!).

Une des choses qui font de Debian une distribution de si haut niveau est son système de paquets. Bien qu'il existe une grande quantité de logiciels dans le format Debian, parfois vous devrez installer un logiciel qui ne l'est pas. Vous pouvez vous demander comment faire vos propres paquets et peut-être pensez vous que c'est une tâche très difficile. Eh bien, si vous êtes vraiment un débutant sous Linux, c'est dur, mais si vous étiez un débutant, vous ne seriez pas en train de lire ce document maintenant. :-) Vous devez en savoir un peu sur la programmation Unix, mais vous n'avez certainement pas besoin d'être un magicien.

Une chose est certaine, cependant : pour correctement développer et maintenir des paquets Debian, vous aurez besoin de journées/homme. Ne vous faites pas d'illusion, pour que votre système fonctionne les responsables doivent à la fois être techiquement compétent et rapides.

Ce document va expliquer toutes les étapes les plus petites (et peut-être a priori insignifiantes), vous aider à créer ce premier paquet, et à gagner de l'expérience pour construire les révisions suivantes ainsi peut-être que d'autres paquets.

Les nouvelles versions de ce document devraient toujours être disponible « online » sur et dans le paquet « Programmes nécessaires au développement.

Avant de commencer quoi que ce soit, vous devriez vous assurer que vous avez correctement installé certains paquets supplémentaires nécessaires pour le développement. Notez que la liste ne contient aucun paquet marqué « essentiel » ou « requis » - nous supposons que vous avez déjà installé ceux-ci.

Cette version du document a été mise à jour pour les paquets de Debian 2.2 (« potato ») et 3.0 (« woody »).

Les paquets suivants sont fournis dans l'installation standard de Debian 2.1, de sorte que vous les avez probablement déjà (ainsi que les paquets supplémentaires dont ils dépendent). Néanmoins, vous devriez le vérifier avec « dpkg -s <paquet> ». ) ) ). Ce paquet va aussi « attirer » plusieur autres paquets tels que ). ). ) )

Vous devrez probablement aussi installer les programmes suivants. fortement recommandés pour les nouveaux responsables. Ils rendent le processus complet bien plus facile à démarrer, et à contrôler par après. (voir , , /usr/share/doc/debhelper/README) ) signer digitalement les paquets. Ceci est spécialement important si vous comptez les distribuer à d'autres personnes, et c'est certainement ce que vous ferez quand votre travail sera inclus dans la distribution Debian (voir ). ). , ). , ). , , /usr/share/doc/lintian/lintian.html/index.html)

Enfin, ces paquets très importants doivent être lus en parallèle à ce document :

Les courtes descriptions qui sont données ci-dessus ne servent que d'introduction à ce que fait chaque paquet. Avant de continuer, veuillez lire attentivement la documentation de chaque programme, au moins l'usage standard. Cela peut vous sembler fastidieux maintenant, mais plus tard vous serez très content de l'avoir fait.

Remarque: pas couvert dans ce document, parce qu'il est obsolète. Veuillez lire pour plus d'information. Plus d'information

Vous pouvez faire deux types de paquets : source et binaire. Un paquet source contient le code que vous pouvez compiler en un programme. Un paquet binaire contient juste le programme fini. Ne mélangez pas les termes comme source du programme et le paquet source du programme ! Veuillez lire les autres manuels si vous avez besoin de plus de détails sur la terminologie.

Debian utilise le terme « responsable » pour la personne qui fait des paquets, « auteur » pour la personne qui a fait le programme, et « responsable amont » pour la personne qui maintient le programme actuellement. D'ordinaire l'auteur et le responsable amont sont une seule et même personne. Si vous avez écrit un programme, et que vous voulez qu'il soit dans Debian, vous pouvez remplir une demande pour devenir un responsable.

Après que vous avez construit votre paquet (ou pendant la création), vous devrez devenir responsable Debian officiel si vous souhaitez que votre programme soit dans la prochaine distribution (si le programme est utile, pourquoi pas ?) Ce processus est expliqué dans la Référence du développeur. Veuillez le lire. Premiers pas Choisir votre programme

Vous avez probablement choisi le paquet que vous voulez créer. La première chose à faire est de vérifier si le paquet si trouve déjà dans la distribution. Si vous utilisez la distribution « stable », le mieux est d'aller sur la . Si vous utilisez une distribution « unstable » courante, vérifiez le avec ces commandes : dpkg -s programme dpkg -l '*programme*'

Si le paquet existe déjà, et bien, installez-le :-) Si il se trouve qu'il est orphelin -- si son responsable est « Debian QA Group », vous devriez être capable de le reprendre. Consultez et pour vérifier que le paquet est bien disponible.

Si vous pouvez adopter le paquet, récupérez les sources (avec quelque chose comme Si le paquet est nouveau, et que vous décidez que vous voulez le voir dans Debian, procécez comme suit : vérifiez que personne d'autre ne travaille déjà sur ce paquet en consultant . Si quelqu'un travaille déjà dessus, contactez-les si vous pensez que vous le devez. Sinon, trouvez un autre programme intéressant que dont personne n'est responsable. le programme doit avoir une licence, si possible libre conformément aux . S'il n'est pas conforme à certaines de ces règles mais peut quand-même être distribué, il peut malgré tout être inclus dans les sections « contrib » ou « non-free » de Debian. Si vous ne savez pas trop où il doit aller, postez la licence sur le programme ne certainement devrait pas être setuid root, ou encore mieux, il ne devrait pas être quoique ce soit setuid ou setgid. le programme ne devrait pas être un démon, ou quelque chose qui va dans les répertoires */sbin, ou ouvre un port comme root. le programme devrait être sous forme de binaire exécutable, les bibliothèques sont plus dur à gérer. il devrait être bien documenté, et le code doit être compréhensible (c'est-à-dire, pas volontairement obscur). vous devriez contacter le(s) auteur(s) du programme pour vérifier qu'ils sont d'accord pour la création du paquet. Il est important d'être à même de consulter le(s) auteur(s) à propos du programme en cas de problèmes spécifiques au programme, aussi n'essayez pas de créer un paquet à partir de programmes non maintenus. enfin, vous devez être sûr qu'il fonctionne, et l'avoir testé pendant quelques temps.

Bien sûr, toutes ces remarques ne sont que des mesures de sécurité, et ont pour but de vous sauver d'utilisateurs fous de rage si vous faites une erreur dans un démon setuid... Quand vous aurez plus d'expérience dans la création des paquets, vous serez capable de faire de tels paquets, mais même les développeurs les plus expérimentés consultent la liste de discussion debian-mentor en cas de doute. Et là les gens seront contents de vous aider.

Pour plus d'informations à ce sujet, consultez la Référence du Développeur. Obtenir le programme, et l'essayer.

La première chose à faire est de trouver et de télécharger le paquet original. Je suppose que vous avez déjà le fichier source que vous avez pris sur la page web de l'auteur. Les sources pour les logiciels Unix libres sont d'habitude au format tar/gzip avec l'extension .tar.gz, et contiennent normalement un sous-répertoire nommé programme-version avec toutes les sources dedans. Si la source de votre programme est disponible dans une autre sorte d'archive (par exemple, le programme se termine par '.Z' ou '.zip'), décompressez-le avec les outils adéquats ou demandez sur la liste de discussion debian-mentors si vous n'êtes pas sûr quant à la façon de le décompresser correctement (indice: utilisez « file archive.extension »).

Comme exemple, je vais utiliser un programme nommé « gentoo », un gestionnaire de fichiers pour X utilisant GTK+. Sachez qu'il y a déjà un paquet pour ce programme, et qu'il a changé substantiellement depuis que ce texte a été écrit la première fois.

Créez un sous-répertoire sous votre répertoire racine nommé « debian » ou « deb » ou quoi que ce soit d'adéquat (ou le nom du programme, ~/gentoo, ferait l'affaire dans notre cas). Placez l'archive téléchargée dedans, et décompressez la avec « tar -xzf gentoo-0.9.12.tar.gz ». Assurez-vous qu'il n'y a pas d'erreurs, même « sans importance », parce qu'alors il y aura des problèmes pour décompresser sur les systèmes d'autres personnes, dont les outils de décompressions pourraient ne pas supporter ces erreurs.

Maintenant vous avez un autre sous-répertoire, nommé « gentoo-0.9.12 ». Allez dans ce répertoire et lisez attentivement la documentation fournie. Il s'agit d'habitude de fichiers nommés README*, INSTALL*, *.lsm ou *.html. Dedans, vous devez trouver les instructions pour compiler et installer correctement le programme (très probablement elles supposent que vous voulez installer dans le répertoire /usr/local/bin; ce n'est pas le cas, mais on reviendra sur ce point plus tard dans ).

La méthode varie d'un programme à l'autre, mais de nombreux programmes modernes viennent avec un script « configure » qui configure les sources selon votre système et s'assure que votre système est à même de les compiler. Après la configuration avec « ./configure », les programmes sont compilés avec « make ». Certains d'entre eux supportent « make check », pour se tester eux-mêmes. L'installation dans les répertoires de destination est généralement obtenue avec « make install ».

Maintenant, essayez de compiler et d'exécuter votre programme, pour vous assurer qu'il fonctionne correctement et ne casse rien d'autre quand il est installé ou qu'il tourne.

Sachez aussi que vous pouvez généralement entrer « make clean » (ou mieux, « make distclean ») pour nettoyer le répertoire de compilation. Parfois, il y a même un « make uninstall » qui peut être utilisé pour retirer tous les fichiers installés. Les noms et versions des paquets

Vous devriez commencer la création du paquet avec un répertoire source complètement propre (originel), ou plus simplement avec les sources fraîchement décompressées.

Pour que le paquet soit correctement construit, vous devez changer le nom du programme en minuscule (si ce n'est déjà fait), et vous devriez changer le répertoire source en <nompaquet>-<version>.

Si le nom du programme consiste en plus d'un mot, réduisez-le à un mot, ou faites une abréviation. Par exemple, le paquet du programme « John's little editor for X » serait nommé johnledx, ou jle4x, ou quoi que vous vouliez, aussi longtemps qu'il reste sous une limite raisonnable, en général 20 caractères.

Vérifiez aussi la version exacte du programme (qui sera inclus dans la version du paquet). Si ce logiciel n'est pas numéroté avec un numéro de version comme X.Y.Z, mais avec une date de distribution, vous pouvez utiliser cette date comme numéro de version, avec comme préfixe '0.0.' (juste au cas où les responsables amont décident de distribuer une jolie version comme 1.0). Donc, si la date est le 19 décembre 1998, vous pouvez utilisez 0.0.19981219 comme chaîne pour la version.

Certains ne seront pas numérotés du tout, auquel cas vous devriez contacter le responsable amont pour voir s'il a une autre méthode de gestion des révisions. « Debianization » initiale

Vérifiez que vous êtes dans le répertoire du code source du programme, et lancez ceci :

dh_make -e votre.adresse@de.responsable -f ../gentoo-0.9.12.tar.gz

Bien sûr, remplacez la chaîne « votre.adresse@de.responsable » avec votre adresse mél pour l'inclure dans l'entrée changelog et dans d'autres fichiers, et le nom du fichier par le nom de la source d'archive originale. Voyez pour plus de détails.

Des informations sont affichées. Il vous demande quelle sorte de paquet vous voulez créer. Gentoo est un paquet binaire simple - il ne crée qu'un exécutable, et donc un seul fichier .deb - donc nous sélectionnons la première option, avec la touche « s », vérifions l'information sur l'écran et confirmons en pressant <enter>.

Rappelons-le, en tant que nouveau responsable, vous ne devriez pas créer des paquets avec plusieurs exécutables, ou des bibliothèques. Ce n'est pas si difficile, mais cela requiert un peu plus de connaissances, et nous n'entrerons pas dans les détails ici.

Notez que vous ne pouvez exécuter dh_make qu'une fois, et qu'il ne se comportera par correctement si vous l'exécutez encore dans le même répertoire déjà debianisé. Cela signifie aussi que vous devrez utiliser une autre méthode pour distribuer une nouvelle révision ou une nouvelle version de votre paquet dans le futur. Lisez plus à ce sujet dans ce texte dans Modifier les sources

Normalement, les programmes s'installent d'eux-mêmes dans les sous-répertoires /usr/local. Mais les paquets Debian ne doivent pas utiliser ce répertoire, car il est réservé à l'usage privé de l'administrateur système (ou de l'utilisateur). Cela signifie que vous devez examinez le système de création de votre programme, en général en commençant par le Makefile. C'est le script que utilisera pour automatiser la création du programme. Pour plus de détails sur les Makefile, regardez .

Notez que si votre programme utilise GNU et/ou , ce qui signifie que les sources incluent des fichiers Makefile.am et/ou Makefile.in, respectivement, vous devrez modifier ces fichiers, parce que chaque appel d'automake va écraser les Makefile.in avec des informations générées à partir des Makefile.am, et que chaque appel de ./configure fera de même avec les fichiers Makefile, avec des données des Makefile.in. Éditer les fichiers Makefile.am requiert des connaissances sur automake, que vous pouvez apprendre dans la section automake d'info, alors qu'éditer les fichiers Makefile.in est globalement identique à l'édition de fichiers Makefile, si ce n'est qu'il faut faire attention à toutes les variables, à savoir toute chaîne entourée de « @ », comme par exemple @CFLAGS@ ou @LN_S@, qui sont remplacées par des valeurs réelles à chaque appel d'autoconf.

Notez qu'il n'y a pas la place ici pour entrer dans tous les détails sur les modifications, mais voici quelques-uns des problèmes qui reviennent souvent. Installer dans un sous-répertoire

La plupart des programmes ont une certaine manière de s'installer dans la structure de répertoire de votre système, de sorte que leurs exécutables sont inclus dans votre $PATH, et que vous trouvez leurs documentation et pages de manuel aux places habituelles. Cependant, si vous faisiez cela, le programme serait installé au milieu de tout ce qui est déjà sur votre système. Les outils de création de paquet auraient plus de difficultés pour décider ce qui appartient ou non à votre paquet.

Dès lors vous devez faire autre chose : installer le programme dans un sous-répertoire temporaire à partir duquel les outils du responsable vont construire un paquet .deb fonctionnel. Tout ce qui est contenu dans ce répertoire sera installé sur le système de l'utilisateur quand il installe votre paquet, la seule différence est que dpkg installera les fichiers dans le répertoire racine.

Ce répertoire temporaire est d'ordinaire créé sous votre répertoire debian/ dans l'arbre des sources décomprimées. Il est normallement nommé debian/tmp ou debian/nom_du_paquet.

Gardez à l'esprit que bien que vous deviez faire en sorte que le programme s'installe sous debian/nom_du_paquet, il doit continuer à s'exécuter correctement quand il est installé sous le répertoire racine, c'est-à-dire quand il est installé à partir du paquet .deb. Aussi vous ne devez pas laisser le système de création coder en dur dans les fichiers du paquet des chaînes de caractères comme /home/me/deb/gentoo-0.9.12/usr/share/gentoo.

Avec des programmes utilisant GNU autoconf, ceci est relativement facile. La plupart de ces programmes ont des fichiers makefile sont par défaut configurés de manière à permettre l'installation dans un répertoire quelconque, en gardant à l'esprit que /usr (par exemple) est le préfix standard. Quand il détecte que votre programme utilise autoconf, dh_make va mettre en place des commandes pour le faire automatiquement, et vous pouvez tout aussi bien passer à la section suivante. Mais avec d'autres programmes, vous devrez plus que probablement examiner et éditer les Makefiles.

Voici les parties concernées du Makefile de gentoo :

# Where to put binary on 'make install'? BIN = /usr/local/bin # Where to put icons on 'make install'? ICONS = /usr/local/lib/gentoo/

Nous voyons que les fichiers sont configurés pour s'installer sous /usr/local/. Changez ces chemins en :

# Where to put binary on 'make install'? BIN = $(DESTDIR)/usr/bin # Where to put icons on 'make install'? ICONS = $(DESTDIR)/usr/share/gentoo/

Mais pourquoi dans ce répertoire, et pas dans un autre ? Parce que Debian n'installe jamais de fichiers sous /usr/local -- cet arbre est réservé à l'usage de l'administrateur système. Sur un système Debian, de tels fichiers doivent plutôt aller sous /usr.

Les positions exactes des exécutables, icônes, documentations, etc, sont spécifiées dans le Standard de la Hiérarchie de Fichiers (voir /usr/share/doc/debian/debian-policy/fhs/). Je vous recommande de le consulter et de lire les sections relatives à votre paquet.

Dès lors, nous devrions installer l'exécutable sous /usr/bin plutôt que /usr/local/bin, la page de manuel sous /usr/share/man/man1 plutôt que sous /usr/local/man/man1, etc. Notez qu'il n'y a pas de page de manel mentionnée dans le fichier makefile, mais comme les Normes Debian requierent que chaque programme en ait une, nous en créerons une plus tard et l'installerons sous /usr/share/man/man1.

Certains programmes n'utilisent pas les variables des fichiers makefile pour définir des chemins comme ceux-ci. Cela signifie que vous pouvez avoir à éditer des fichiers sources C réels pour les faire utiliser les positions correctes. Mais où et que chercher ? Vous pouvez trouver où en lançant :

grep -rn usr/local/lib *.[ch]

Grep va récursivement parcourir l'arbre des sources et vous dire le nom des fichiers et le numéro de ligne où il trouve une occurence.

Éditez ces fichers et à ces lignes remplacez /usr/local/* par /usr/* -- et c'est à peu près tout. Soyez attentif à ne pas casser le reste du code ! :-)

Après quoi vous devriez trouver la cible d'installation (cherchez une ligne qui commence avec « install: », d'ordinaire cela fonctionne) et renommez toutes les références aux répertoires autres que ceux définis au début du Makefile. Auparavant, la cible d'installation de gentoo disait :

install: gentoo install ./gentoo $(BIN) install icons/* $(ICONS) install gentoorc-example $(HOME)/.gentoorc

Après votre modification elle dit : install: gentoo-target install -d $(BIN) $(ICONS) $(DESTDIR)/etc install ./gentoo $(BIN) install -m644 icons/* $(ICONS) install -m644 gentoorc-example $(DESTDIR)/etc/gentoorc

Vous aurez sûrement remarqué qu'il y a maintenant une commande install -d avant les autres commandes dans la rêgle. Le fichier makefile originel ne l'avait pas parce que habituellement /usr/local/bin et les autres répertoires existent déjà sur le système que « make install » est exécuté. Cependant, comme nous installerons dans nos propres répertoires vides (ou même non-existant), nous aurons à créer chacun de ces répertoires.

Nous pouvons ajouter d'autres choses à la fin de la rêgle, comme l'installation de la documentation additionelle que l'auteur amont oublie parfoit :

install -d $(DESTDIR)/usr/share/doc/gentoo/html cp -a docs/* $(DESTDIR)/usr/share/doc/gentoo/html

Le lecteur attentif notera que j'ai changé « gentoo » en « gentoo-target » dans la ligne « install: ». C'est ce qu'on appelle une correction de bogue sans rapport :-)

Chaque fois que vous faites des modifications qui ne sont pas spécifiquement lié à Debian, envoyez les au responsable amont pour qu'elles puissent être inclue dans la version suivante du programme et que tout le monde puisse en bénéficier. Souvenez-vous aussi de ne pas rendre vos corrections spécifiques à Debian ou Linux (ou même Unix!) avant de les envoyer -- faites les portables. Cela rendra vos corrections beaucoup plus faciles à appliquer.

Remarquez que vous ne devez pas envoyer les fichiers debian/* en amont. Bibliothèques différentes

Il y a souvent un problème commun : des bibliothèques sont souvent différentes d'une plate-forme à l'autre. Par exemple, Makefile peut contenir une référence à une bibliothèque qui n'existe pas sur les systèmes Debian. Dans ce cas, nous devons la changer en une bibliothèque qui existe dans Debian, et qui sert à la même chose.

Ainsi, s'il y a une ligne dans le Makefile (ou Makefile.in) de votre programme qui dit quelque chose comme ceci (et votre programme ne compile pas) :

LIBS = -lcurses -lquelquechose -lautrechose

Changez la en ceci, et cela marchera probablement :

LIBS = -lncurses -lquelquechose -lautrechose

(L'auteur réalise que ceci n'est pas le meilleur exemple dans la mesure où notre paquet libncurses est maintenant livrées avec un lien symbolique libcurses.o, mais il n'en a pas trouvé de meilleur. Toutes suggestions bienvenues :-) Ce qui est requis sous debian/

Il y a un nouveau sous-répertoire sous le répertoire des sources du programme ('gentoo-0.9.12'), nommé « debian ». Il y a un certain nombre de fichiers dans ce répertoire que vous devriez éditer pour configurer le comportement du paquet. Les plus importants d'entre eux sont « control », « changelog », « copyright » et « rules », qui sont requis pour tous les paquets. fichier « control »

Ce fichier contient plusieurs valeurs que Voici le fichier « control » que dh_make crée pour nous.

1 Source: gentoo 2 Section: unknown 3 Priority: optional 4 Maintainer: Josip Rodin <jrodin@jagor.srce.hr> 5 Build-Depends: debhelper (>> 3.0.0) 6 Standards-Version: 3.5.2 7 8 Package: gentoo 9 Architecture: any 10 Depends: ${shlibs:Depends} 11 Description: <insert up to 60 chars description> 12 <insert long description, indented with spaces> (J'ai ajouté les numéros de ligne.)

Les lignes de 1 à 6 sont les informations de contrôle pour le paquet source.

La ligne 1 est le nom du paquet source.

La ligne 2 est la section de la distribution dans laquelle ce paquet va.

Comme vous l'avez constaté, Debian est divisée en sections: main (logiciels libres), non-free (logiciels pas vraiment libres), et contrib (logiciels libres qui dépendent de logiciels non libres). Sous celles-ci, il y a des sous-sections logiques qui décrivent de manière concise les paquets qui s'y trouvent. Ainsi nous avons « admin » pour les programmes réservés à l'administrateur, « base » pour les outils de base, « devel » pour les outils de programmation, « doc » pour la documentation, « libs » pour les bibliothèques « mail » pour les lecteurs et les démons de courriel, « net » pour les applications et démons réseaux, « x11 » pour les programmes X11 qui ne sont pas plus appropriés ailleurs, et bien d'autres.

Changeons donc la section en x11 (un préfixe « main/ » est implicite, donc nous pouvons l'omettre).

La ligne 3 décrit l'importance pour l'utilisateur d'installer ce paquet. Lisez le manuel des Normes pour des informations sur ces valeurs. La priorité « optional » marche habituellement pour les nouveaux paquets.

Les sections et les priorités sont utilisés par des interfaces comme Comme c'est un paquet de priorité normale et qu'il n'entre pas en conflit avec quoi que ce soit, nous le laissons à « optional ».

La ligne 4 est le nom et l'adresse mél du responsable. Assurez-vous que ce champ contient une entête « To: » valide pour un courriel, car après le téléchargement, le système de suivi des bogues l'utilisera pour vous délivrer les courriels de bogues. Évitez d'utiliser des virgules, esperluètes ou parenthèses.

La 5e ligne contient la liste des paquets nécessaires pour construire le paquet. Certains paquets comme gcc ou make sont implicites, voyez le paquet Vous pouvez aussi avoir Build-Depends-Indep, Build-Conflicts et d'autres champs ici. Ces données seront utilisées par le logiciel de construction de paquets automatique Debian pour créer les paquets binaires pour d'autres plate-formes d'ordinateurs. Lisez le manuel des Normes pour plus d'informations sur les dépendances de construction et la Référence du Développeur pour plus d'information sur ces autres plate-formes (architectures) et comment porter des logiciels vers celles-ci.

Il se trouve que Gentoo a aussi besoin de La ligne 6 est la version du standard de Normes Debian que ce paquet respecte, la version du manuel des Normes que vous lisez quand vous créez votre paquet.

La ligne 8 est le nom du paquet binaire. C'est d'ordinaire le même que le nom du paquet source, mais ce ne doit pas être nécessairement le cas.

La ligne 9 décrit l'architecture CPU pour laquelle le paquet binaire peut être compilé. Nous le laissons à « any » car trouvera la valeur appropriée pour toute machine sur laquelle ce paquet sera compilé.

Si votre paquet est indépendant d'une architecture (par exemple, un script shell ou Perl, ou un document), changez cette entrée en « all », et lisez plus tard dans comment utiliser la règle « binary-indep » au lieu de « binary-arch » pour construire le paquet.

La ligne 10 montre une des caractéristiques les plus puissantes du système de paquet Debian. Les paquets peuvent être liés entre eux de plusieurs façons. À part Depends: les autres champs décrivant ces relations sont Recommends:, Suggests:, Pre-Depends:, Conflicts:, Provides:, et Replaces:.

Les outils de gestion de paquets se comportent d'ordinaire de la même manière quand ils gèrent ces relations; sinon, ce sera expliqué. (voir , , , , etc.)

Voici ce que les dépendances veulent dire :

Depends:

Le paquet ne sera pas installé à moins que les paquets dont il dépend ne soient installés. Utilisez-le si votre programme ne s'exécute absolument pas (ou cause des dégâts sérieux) tant qu'un paquet particulier n'est pas présent. Recommends:

Des interfaces comme dselect ou aptitude vous demanderons d'installer les paquets recommandés en même temps que votre paquet; dselect insistera même. dpkg et apt-get ignorerons ce champ, cependant. Utilisez le pour les paquets qui ne sont pas vraiment indispensables mais qui sont typiquement utilisés avec votre programme. Suggests:

Quand un utilisateur installe votre programme, toute interface lui demandera probablement s'il faut installer les programmes qu'il suggère. Dpkg et apt-get ne s'en soucient pas. Utilisez le pour les paquets qui marchent bien avec votre programme mais qui ne sont pas nécessaires. Pre-Depends:

Ceci est plus fort que Depends. Le paquet ne sera pas installé à moins que les paquets dont il pré-dépend ne soient installés et correctement configurés. Utilisez le très rarement et seulement après en avoir discuté sur la liste de discussion debian-devel. Traduisez: ne l'utilisez pas du tout. :-) Conflicts:

Le paquet se sera pas installé avant que les paquets avec lesquels il est en conflit n'aient été retirés. Utilisez ceci si votre programme ne peut absolument pas fonctionner ou s'il cause d'énormes problèmes quand un paquet particulier est présent. Provides:

Quand il y a plusieurs alternatives pour certains types de paquets, des noms virtuels ont été définis. Vous pouvez trouver la liste complète se trouve dans /usr/share/doc/debian-policy/virtual-package-name-list.text.gz. Utilisez ceci si votre programme fournit une fonction d'un paquet virtuel existant. Replaces:

Utilisez ceci quand votre programme remplace des fichiers d'un autre paquet, ou remplace complètement un autre paquet (utilisé en conjonction avec Conflicts:). Les fichiers du paquet nommé seront écrasés par les fichiers de votre paquet.

Tous ces champs ont une syntaxe uniforme. Il s'agit d'une liste de paquets séparés par des virgules. Ces noms de paquets peuvent aussi être une liste d'alternatives, séparés par des symboles barre verticale | (symbole tube).

Le domaine d'application des champs peut être restreints à des versions particulières de chaque paquet nommé. Ces versions sont listées entre parenthèses après chaque nom de paquet individuel, et doivent contenir une relation de la liste suivante suivie par un numéro de version. Les relations autorisées sont <<, <=, =, >= et >> pour strictement plus petit, plus petit ou égal, exactement égal, plus grand ou égal et strictement plus grand, respectivement. Par exemple, Depends: foo (>= 1.2), libbar1 (= 1.3.4) Conflicts: baz Recommends: libbaz4 (>> 4.0.7) Suggests: quux Replaces: quux (<< 5), quux-foo (<= 7.6)

La dernière caractéristique que vous devez connaître est ${shlibs:Depends}. Après que votre paquet ait été construit et installé dans le répertoire temporaire, le scannera pour les exécutables et bibliothèques, déterminera leurs dépendances en bibliothèques partagées et détectera dans quels paquets elles se trouvent. Il passera la liste à qui l'insérera à la bonne place, et vous ne devrez pas vous en soucier. Ceci étant dit, nous pouvons laisser la ligne 10 exactement comme elle est maintenant, et insérer après une ligne disant Suggests: file, car gentoo peut utiliser certaines fonctionalités fournies par ce programme/paquet.

La ligne 10 est celle où la liste de suggestions va. Ici on ne met que « file », parce que gentoo peut utiliser certaines capacités de ce programme/paquet.

La ligne 11 est la description courte. L'écran de la plupart de gens est large de 80 colonnes, aussi cela ne devrait pas dépasser les 60 caractères. Je le change en « A fully GUI configurable X file manager using GTK+ ».

À la ligne 12 commence la description longue. Celle-ci devrait être un paragraphe qui donne plus de détails sur le paquet. La colonne 1 de chaque ligne doit être vide. Il ne peut y avoir de ligne vide, mais vous pouvez mettre un seul . (point) dans la colonne 2 pour simuler une ligne vide. De plus, il ne peut pas y avoir plus d'une ligne vide après la description longue.

Finalement, voici le fichier control mis à jour:

1 Source: gentoo 2 Section: x11 3 Priority: optional 4 Maintainer: Josip Rodin <jrodin@jagor.srce.hr> 5 Build-Depends: debhelper (>> 3.0.0), xlibs-dev, libgtk1.2-dev, libglib1.2-dev 6 Standards-Version: 3.5.2 7 8 Package: gentoo 9 Architecture: any 10 Depends: ${shlibs:Depends} 11 Suggests: file 12 Description: A fully GUI configurable GTK+ file manager 13 gentoo is a file manager for Linux written from scratch in pure C. It 14 uses the GTK+ toolkit for all of its interface needs. gentoo provides 15 100% GUI configurability; no need to edit config files by hand and re- 16 start the program. gentoo supports identifying the type of various 17 files (using extension, regular expressions, or the 'file' command), 18 and can display files of different types with different colors and icons. 19 . 20 gentoo borrows some of its look and feel from the classic Amiga file 21 manager "Directory OPUS" (written by Jonathan Potter). (J'ai ajouté les numéros de ligne.) fichier « copyright »

Ce fichier contient les informations sur les ressources amonts, le copyright et la licence du paquet. Le format n'est pas dicté par les Normes, mais son contenu l'est (voir section 13.6 « Copyright Information »).

dh_make en crée un par défaut, qui ressemble à ceci :

1 This package was debianized by Josip Rodin <jrodin@jagor.srce.hr> on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from <fill in ftp site> 5 6 Upstream Author(s): <put author(s) name and email here> 7 8 Copyright: 9 10 <Must follow here> (J'ai ajouté les numéros de ligne.)

Les choses importantes à ajouter à ce fichier sont l'endroit où vous avez trouvé ce paquet, ainsi que le copyright et la licence d'exploitation réelle (incluez-la en entier). Si la licence est une des licences de logiciel libre populaires comme GNU GPL ou LGPL, BSD ou Artistic, vous pouvez juste faire référence au fichier approprié dans le répertoire /usr/share/common-licenses/, qui existe sur chaque système Debian.

En bref, voici ce à quoi le fichier copyright de gentoo devrait ressembler :

1 This package was debianized by Josip Rodin <jrodin@jagor.srce.hr> on 2 Wed, 11 Nov 1998 21:02:14 +0100. 3 4 It was downloaded from: ftp://ftp.obsession.se/gentoo/ 5 6 Upstream Author: Emil Brink <emil@obsession.se> 7 8 This software is copyright (c) 1998-99 by Emil Brink, Obsession 9 Development. 10 11 You are free to distribute this software under the terms of 12 the GNU General Public License. 13 On Debian systems, the complete text of the GNU General Public 14 License can be found in the file `/usr/share/common-licenses/GPL'. (J'ai ajouté les numéros de ligne.) changelog

C'est un fichier requis, qui a un format spécial décrit dans le Manuel des Normes section 5.3 « debian/changelog ». Ce format est utilisé par dpkg et d'autres programmes pour obtenir le numéro de version, de révision, de distribution et l'urgence de votre paquet.

Pour vous, il est aussi important, puisqu'il est bon de documenter toutes les modifications que vous avez faites. Cela aidera les gens qui téléchargent votre paquet à voir si il y a des problèmes non résolus à propos desquels ils doivent être immédiatement mis au courant. Il sera sauvé sous « /usr/share/doc/gentoo/changelog.Debian.gz » dans le paquet binaire.

Dh_make en crée un par défaut, et c'est à ceci qu'il ressemble :

1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial Release. 4 5 -- Josip Rodin <jrodin@jagor.srce.hr> Wed, 11 Nov 1998 21:02:14 +0100 6 7 Local variables: 8 mode: debian-changelog 9 End: (J'ai ajouté les numéros de ligne.)

La ligne 1 est le nom du paquet, la version, la distribution et l'urgence. Le nom doit correspondre au nom du paquet source, la distribution devrait être « unstable » (ou même « experimental », et l'urgence ne devrait pas être changée en quoique ce soit de plus haut que « low ». :-)

Les lignes 3 à 5 sont l'entrée d'audit, où vous documentez les modifications faites dans la révision du paquet (pas les modifications amont - il y a un fichier spécial pour cela, créé par les auteurs en amont, que vous installerez comme /usr/share/doc/gentoo/changelog.gz). Les nouvelles lignes doivent être ajoutées juste avant la première ligne qui commence avec une astérisque (« * »). Vous pouvez le faire avec , ou manuellement avec un éditeur de texte.

Vous obtiendrez quelque chose comme :

1 gentoo (0.9.12-1) unstable; urgency=low 2 3 * Initial Release. 4 * This is my first Debian package. 5 * Adjusted the Makefile to fix $DESTDIR problems. 6 7 -- Josip Rodin <jrodin@jagor.srce.hr> Wed, 11 Nov 1998 21:02:14 +0100 8 (J'ai ajouté les numéros de ligne.)

Vous pouvez en apprendre plus sur la mise à jour du fichier changelog plus loin dans . fichier « rules »

Maintenant nous devons examiner les règles que va utiliser pour créer vraiment le paquet. Ce fichier est en fait un autre Makefile, mais différent de celui/ceux des sources amont. Contrairement aux autres fichiers sous debian/, celui-ci est marqué comme exécutable.

Chaque fichier « rules », comme tout autre Makefile, consiste en plusieurs règles indiquant comment construire les sources. Les règles sont des cibles, noms de fichiers ou d'actions à exécuter (par exemple, « build: » ou « install: »). Les règles que vous voulez exécuter doivent être données comme argument à la ligne de commande (par exemple, 'rules build' ou 'rules install'). Après le nom de cible, vous pouvez nommer les dépendances, programme ou fichier dont la cible dépend. Après cela il peut y avoir un nombre quelconque de commandes indentés par <tab>!, jusqu'à ce qu'une ligne vide soit trouvée. Une nouvelle rêgle commence avec une déclaration de cible dans la première colonne. Les lignes vides ainsi que celles qui commencent par un « # » (dièse) sont considérées comme des commentaires et ignorées.

Tout ceci vous semble probablement confus pour l'instant, mais cela va devenir clair à l'examen du fichier « rules » que dh_make nous donne par défaut. Vous devriez avoir lu l'entrée « make » dans info pour plus d'information.

Ce qu'il faut savoir à propos du fichier rules créé par dh_make, est qu'il s'agit juste d'une suggestion. Il fonctionnera pour des paquets simples, mais pour ceux qui sont plus compliqués, vous ne devez pas craindre de le modifier pour le faire correspondre à vos besoins. Les seules choses que vous ne pouvez pas changer sont les noms des règles, car tous les outils utilisent ces noms comme requis par le manuel des Normes.

Voici (approximativement) ce à quoi ressemble le fichier par défaut debian/rules généré pour nous par dh_make :

1 #!/usr/bin/make -f 2 # Sample debian/rules that uses debhelper. 3 # GNU copyright 1997 to 1999 by Joey Hess. 4 5 # Uncomment this to turn on verbose mode. 6 #export DH_VERBOSE=1 7 8 # This is the debhelper compatibility version to use. 9 export DH_COMPAT=3 10 11 ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) 12 CFLAGS += -g 13 endif 14 ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) 15 INSTALL_PROGRAM += -s 16 endif 17 18 build: build-stamp 19 build-stamp: 20 dh_testdir 21 22 # Add here commands to compile the package. 23 $(MAKE) 24 #/usr/bin/docbook-to-man debian/gentoo.sgml > gentoo.1 25 26 touch build-stamp 27 28 clean: 29 dh_testdir 30 dh_testroot 31 rm -f build-stamp 32 33 # Add here commands to clean up after the build process. 34 -$(MAKE) clean 35 36 dh_clean 37 38 install: build 39 dh_testdir 40 dh_testroot 41 dh_clean -k 42 dh_installdirs 43 44 # Add here commands to install the package into debian/gentoo. 45 $(MAKE) install DESTDIR=$(CURDIR)/debian/gentoo 46 47 # Build architecture-independent files here. 48 binary-indep: build install 49 # We have nothing to do by default. 50 51 # Build architecture-dependent files here. 52 binary-arch: build install 53 dh_testdir 54 dh_testroot 55 # dh_installdebconf 56 dh_installdocs 57 dh_installexamples 58 dh_installmenu 59 # dh_installlogrotate 60 # dh_installemacsen 61 # dh_installpam 62 # dh_installmime 63 # dh_installinit 64 dh_installcron 65 dh_installman 66 dh_installinfo 67 # dh_undocumented 68 dh_installchangelogs ChangeLog 69 dh_link 70 dh_strip 71 dh_compress 72 dh_fixperms 73 # dh_makeshlibs 74 dh_installdeb 75 # dh_perl 76 dh_shlibdeps 77 dh_gencontrol 78 dh_md5sums 79 dh_builddeb 80 81 binary: binary-indep binary-arch 82 .PHONY: build clean binary-indep binary-arch binary install (J'ai ajouté les numéros de ligne).

Vous avez probablement l'habitude de la ligne 1 avec les scripts shell et perl. Cela signifie que ce fichier doit être exécuté par /usr/bin/make.

La signification des variables DH_* mentionnées des lignes 6 à 9 devrait être évidente à partir de la description courte. Pour plus d'information sur DH_COMPAT, lisez la section « Debhelper compatibility levels » de la page de manuel .

Les lignes 11 à 16 sont un squelette de support pour les paramètres DEB_BUILD_OPTIONS, décrits dans les Normes section 11.1 « Binaries ». Fondamentalement, ces choses déterminent si l'exécutable doit être construit avec les symboles de déboguage, et si ils devraient être retirés à l'installation. Une fois encore, il s'agit juste d'un squelette, une indication que vous devriez le faire. Vous devriez vérifier comment le système de construction amont gère l'inclusion des symboles de déboguage, et comment il les retire à l'installation, et implémenter cela vous-même.

D'habitude, vous pouvez dire à gcc de compiler avec « -g » en utilisant la variable CFLAGS -- si c'est le cas pour votre paquet, propagez la variable en ajoutant CFLAGS="$(CFLAGS)" à l'invocation de $(MAKE) dans la rêgle de construction (vois plus bas). Alternativement, si votre paquet utilise un script de configuration autoconf, vous pouvez la lui passer en préfixant la chaîne ci-dessus à l'appel à ./configure dans la rêgle de construction.

Pour ce qui est de retirer les symboles, les programmes sont configurés courament pour s'installer avec, et souvent sans option pour changer cela. Heureusement, vous avez toujours qui détecte quand le drapeau DEB_BUILD_OPTIONS=nostrip est mis, et qui quitte silencieusement.

Les lignes 18 à 26 décrivent la rêgle « build » (et son enfant « build-stamp »), qui exécute make avec le fichier Makefile de l'application pour compiler le programme. Nous en dirons plus sur l'exemple commenté docbook-to-man plus loin dans .

La règle « clean », spécifiée aux lignes 28-36, efface tous les binaires inutiles et les trucs générés automatiquement, laissés là par une construction du paquet. Cette règle doit être opérationnelle tout le temps (même si les répertoires sources sont nettoyés.!), donc vous devriez utiliser les options pour forcer (p.e. pour rm, c'est « -f ») ou pour ignorer la valeur de retour (les échecs), avec un « - » devant le nom de la commande.

Le processus d'installation, la règle « install », commence à la ligne 38. Fondamentalement, elle exécute la rège install du fichier Makefile du programme, mais installe dans le répertoire $(CURDIR)/debian/gentoo - c'est pour cette raison que nous avons spécifié $(DESTDIR) comme racine de l'installation dans le Makefile de gentoo.

Comme le commentaire le laisse à penser, la règle « binary-indep », sur la ligne 48, est utilisée pour construire des paquets indépendants de l'architecture. Comme il n'y en a pas dans cet exemple, rien n'est fait.

Ensuite on trouve la règle « binary-arch », des lignes 52 à 73, pour laquelle nous exécutons plusieurs petits utilitaires du paquet debhelper qui font quelques opérations sur votre paquet pour le rendre conforme aux Normes Debian.

Si votre paquet est un « Architecture: all », vous devez inclure toutes les commandes pour construire le paquet sous la rêgle « binary-indep », et laisser la rêgle « binary-arch » vide.

Les noms des programmes debhelper commencent par dh_ et la suite indique ce que chaque petit utilitaire fait. Tout cela est plutôt explicite, mais voici quelques explications supplémentaires : vérifie que vous êtes dans le bon répertoire (i.e. le répertoire racine des sources), vérifie que vous avez les permissions root, nécessaire pour les cibles « binary-arch », « binary-indep » et « clean », copie les pages de manuel à la bonne place dans le répertoire de destination, vous devez juste lui dire où elles sont, relativement au répertoire racine des sources, retire les entêtes de débogage des fichiers exécutables pour les rendre plus petits, compresse les pages de manuel et la documentation plus large que 4 kb, avec , copie les fichiers relatifs au paquet (p.e. les scripts du responsable) sous le répertoire debian/gentoo/DEBIAN, calcule les dépendances des bibliothèques et des exécutables, génère et installe une version soigneusement ajustée du le fichier control dans debian/gentoo/DEBIAN génère les sommes de contrôle MD5 pour tous les fichiers dans le paquet.

Pour une information plus complète sur ce que font tous ces scripts dh_*, et ce que sont leurs options, lisez les pages de manuel respectives. Il y en a d'autres, potentiellement très utiles, qui ne sont pas mentionnés ici. Si vous en avez besoin, lisez la documentation de debhelper.

La section binary-arch est celle où vous devriez vraiment commenter ou retirer toutes les lignes qui appellent des fonctionalités dont vous n'avez pas besoin. Pour gentoo, je commente les lignes concernant examples, cron, init, man et info, simplement parce que gentoo n'en a pas besoin. De plus, à la ligne 68, je remplace « ChangeLog » par « FIXES », parce que c'est le nom du fichier des modifications amont.

Les deux dernières lignes (avec toutes celles qui ne sont pas expliquées ici) sont juste des choses plus ou moins nécessaires, à propos desquelles vous pouvez lire dans le manuel de make, et dans le manuel des Normes. Pour l'instant il n'est pas important d'en savoir plus. Autres fichiers dans le répertoire debian/

Vous verrez qu'il y a plusieurs autres fichiers dans le sous-répertoire debian, la plupart d'entre eux avec le suffixe « .ex », ce qui signifie qu'ils sont des exemples. Jetez un coup d'oeil à chacun d'entre eux. Si vous souhaitez ou devez utiliser une de ces options : lisez la documentation relative (astuce : le manuel des Normes), si nécessaire, modifiez les fichers selon vos besoins, renommez-les pour retirer le suffice « .ex » si ils en ont, modifiez le fichier « rules » si nécessaire.

Certains de ces fichiers, les plus utilisés, sont décrits dans les sections suivantes. README.Debian

Tous les détails ou différences entre le paquet original et votre version debianisée devraient être documentés ici.

dh_make en crée un par défaut, voici ce à quoi il ressemble :

gentoo for Debian ----------------- <possible notes regarding this package - if none, delete this file> -- Josip Rodin <jrodin@jagor.srce.hr>, Wed, 11 Nov 1998 21:02:14 +0100

Puisque nous n'avons rien en particulier à mettre ici, nous effaçons le fichier. conffiles.ex

L'une des choses les plus irritantes à propos des logiciels est de consacrer beaucoup de temps et d'efforts pour configurer un programme, et de voir une seule mise à jour détruire tous vos changements. Debian résout ce problème en marquant les fichiers de configuration de sorte que quand vous mettez à jour un paquet, il vous sera demandé si vous voulez gardez votre vieille configuration ou pas.

La façon de procéder pour un paquet est d'entrer le chemin complet de chaque fichier de configuration (en général sous /etc), un par ligne dans un fichier nommé Si votre programme utilise des fichiers de configuration, mais les réécrit aussi de son côté, il vaut mieux ne pas les marquer comme conffiles, parce que dpkg va alors interroger les utilisateurs pour vérifer les modifications tout le temps.

Si le programme que vous paquetez requiert que chaque utilisateur modifier le fichier de configuration pour fonctionner tout court, envisagez de ne pas le marquer non plus comme conffile.

Vous pouvez gérer des fichiers d'exemple de configuration à partir des « scripts du responsable ». Lisez pour plus d'information.

Si votre programme n'a pas de conffiles, vous pouvez tranquillement effacer le fichier cron.d.ex

Si votre paquet requiert des tâches programmées régulièrement pour fonctionner correctement, vous pouvez utiliser ce fichier pour le configurer.

Notez que ceci n'inclut pas la rotation des journaux; pour cela, voyez et .

Sinon, supprimez-le. dirs

Ce fichier spécifie les répertoires dont nous avons besoin mais que la procédure d'installation normale (make install) ne crée pas.

Par défaut, il ressemble à ceci :

usr/bin usr/sbin

Remarquez que le préfixe slash n'est pas inclus. Nous devrions normalement le changer comme ceci :

usr/bin usr/man/man1

mais ces répertoires sont déjà créés dans Makefile, donc nous n'avons pas besoin de ce fichier, et allons plutôt l'effacer. docs

Ce fichier spécifie les noms des fichiers de documentation que dh_installdocs peut installer pour nous dans le répertoire temporaire.

Par défault, il inclut tout les fichiers, existant dans le répertoire racine des sources, qui sont nommés « BUGS », « README* », « TODO », etc.

Pour gentoo, j'ai aussi inclus d'autres choses :

BUGS CONFIG-CHANGES CREDITS ONEWS README README.gtkrc TODO

Nous pouvons aussi retirer ce fichier et à la place lister ces fichiers directement dans la ligne de commande dh_installdocs BUGS CONFIG-CHANGES CREDITS ONEWS README \ README.gtkrc TODO

Aussi incroyable que cela puisse être, vous pouvez ne pas avoir de tels fichiers dans les sources de votre paquet. Dans ce cas, vous pouvez tranquillement effacer ce fichier. Mais ne retirez l'appel emacsen-*.ex

Si votre paquet fournit des fichiers Emacs qui peuvent être byte-compilés au moment de l'installation, vous pouvez utiliser ces fichiers pour les configurer.

Ils sont installés dans le répertoire temporaire par , donc n'oubliez pas de décommenter cette ligne dans le fichier Si vous n'en avez pas besoin, effacez-les. init.d.ex

Si votre paquet est un démon qui doit être lancé au démarrage du système, vous avez de toute évidence ignoré mes recommendations initiales, n'est-ce-pas ? :-)

Ceci est un squelette de fichier générique pour un fichier script /etc/init.d/, donc vous aurez à l'éditer, beaucoup. Il est installé dans le répertoire temporaire par .

Si vous n'en avez pas besoin, effacez-le. manpage.1.ex, manpage.sgml.ex

Votre programme devrait avoir une page de manuel. S'il n'en a pas, chacun de ces fichiers est un squelette que vous pouvez remplir.

Les pages de manuel sont normalement écrites en . L'exemple pour une description brève de la façon d'éditer ce genre de fichier.

D'un autre côté, si vous préférez écrire du SGML à la place de nroff, vous pouvez utiliser le patron installer le paquet ajouter retirer le commentaire de l'appel docbook-to-man dans la rêgle « build » de votre fichier

Et souvenez-vous de renommer le fichier en quelque chose comme Le nom du fichier de la page de manuel finale devrait inclure le nom du programme qu'elle documente, donc nous le renommons de « manpage » en « gentoo ». Le nom du fichier inclut aussi « .1 » comme premier suffixe, ce qui signifie que c'est une page de manuel pour une commande utilisateur. Assurez-vous de vérifier que cette section est bien la bonne. Voici une courte liste des sections de pages de manuel :

Section | Description | Notes 1 Commandes utilisateur Commandes ou scripts exécutables. 2 Appel système Fonctions fournies par le noyau. 3 Appel bibliothèque Fonctions des bibliothèques système. 4 Fichiers spéciaux D'ordinaire trouvés dans /dev. 5 Formats de fichiers Par ex. le format /etc/password. 6 Jeux Ou d'autres programmes frivoles. 7 Paquets de macros Comme les macros de man. 8 Administration système Des programmes d'habitude exécutées par root. 9 Routines noyau Appels non standards et routines internes.

Donc, la page de manuel de gentoo devrait être appelée gentoo.1, ou gentoo.1x parce que c'est un programme X11. Il n'y avait pas de page de manuel gentoo.1 dans les sources original, donc j'en ai écrit un à partir de l'exemple et de la documentation amont. menu.ex

Les utilisateurs de X Window ont un gestionnaire de fenêtres avec un menu qui peut être configuré. S'ils ont installés le paquet Voici le fichier ?package(gentoo):needs=X11|text|vc|wm section=Apps/see-menu-manual\ title="gentoo" command="/usr/bin/gentoo"

Le premier champ après le caractère deux-point est « needs », et il indique le genre d'interface dont a besoin le programme. Changez ceci en une des alternatives listées, p.e. « text » ou « X11 ».

Le suivant est « section », avec le menu et le sous-menu dans lesquels l'entrée devrait apparaître. La liste courant des sections est dans : /usr/share/doc/debian-policy/menu-policy.html/ch2.html#s2.1.

le champ « title » est le nom du programme. Vous pouvez le commencer par une majuscule si vous le souhaitez. Mais gardez-le court.

Enfin, le champ « command » est la commande qui lance le programme.

Maintenant nous changeons l'entrée menu en ceci :

?package(gentoo): needs=X11 section=Apps/Tools title="Gentoo" command="gentoo"

Vous pouvez aussi ajouter d'autres champs comme « longtitle », « icon », « hint », etc. Voir , et /usr/share/doc/debian-policy/menu-policy.html/ pour plus d'information. watch.ex

Ce fichier est utilisé pour configurer les programmes et de (dans le paquet Voici ce que j'y ai mis :

# watch control file for uscan # Site Directory Pattern Version Script ftp.obsession.se /gentoo gentoo-(.*)\.tar\.gz debian uupdate

Astuce: connectez-vous à Internet, et essayez d'exécuter « uscan » dans le répertoire du programme une fois que vous avez créer ce fichier. Et lisez les manuels. :-) ex.package.doc-base

Si votre paquet a de la documentation autre que des pages de manuel et des documents info, vous devriez utiliser le fichier , ou .

Cela inclut normalement les fichiers HTML, PS et PDF, délivrés dans /usr/share/doc/nom_du_paquet/.

Voici ce à quoi le fichier doc-base de gentoo ressemble :

Document: gentoo Title: Gentoo Manual Author: Emil Brink Abstract: This manual describes what Gentoo is, and how it can be used. Section: Apps/Tools Format: HTML Index: /usr/share/doc/gentoo/html/index.html Files: /usr/share/doc/gentoo/html/*.html

Pour plus d'information sur le format de ce fichier, voir et le manuel de /usr/doc/doc-base/doc-base.html/index.html. postinst.ex, preinst.ex, postrm.ex, prerm.ex

Ces fichiers sont nommés scripts de responsable. Ce sont des scripts placés dans la zone de contrôle du paquet et sont exécutés par Pour l'instant, vous devriez éviter les scripts de responsable si vous le pouvez parce qu'ils ont tendance à être complexes. Pour plus d'information regardez dans la section 6 du Manuel de Création de Paquets, et examinez les fichiers d'exemples fournis par dh_make. Construire le paquet

Nous devrions maintenant être prêt à construire le paquet. Reconstruction complète

Allez dans le répertoire principal du programme et lancez ceci :

dpkg-buildpackage -rfakeroot

Ceci fera tout pour vous. Il va : nettoyer l'arbre des sources (debian/rules clean), en utilisant construite le paquet source (dpkg-source -b) construire le programme (debian/rules build) construire le paquet binaire (debian/rules binary), en utilisant signer le fichier source créer et signer le fichier de téléchargement

La seule entrée qui vous sera demandée est votre phrase de passe secrète GPG, deux fois.

Une fois que c'est fait, vous verrez les fichiers suivants dans le répertoire au-dessus (~/debian) :

gentoo_0.9.12.orig.tar.gz

Ceci est le code source original, simplement renommé pour être conforme aux standards Debian. Notez qu'il a été créé en utilisant l'option « -f » du programme gentoo_0.9.12-1.dsc

Ceci est un résumé du contenu du code source. Ce fichier est généré à partir du fichier « control », et est utilisé pour décompresser les sources avec . Ceci est un fichier signé en PGP, de sorte que les gens peuvent être sûrs qu'il s'agit bien du vôtre. gentoo_0.9.12-1.diff.gz

Ce fichier compressé contient chacune des additions que vous avez faites au code source original, sous une forme connue comme « différence unifiée ». Il est crée et utilisé par . Attention : si vous ne nommez pas le paquet source original nomdupaquet_version.orig.tar.gz, dpkg-source -x gentoo_0.9.12-1.dsc. gentoo_0.9.12-1_i386.deb

Ceci est le paquet binaire complété. Vous pouvez utiliser gentoo_0.9.12-1_i386.changes

Ce fichier contient toutes les modifications faites dans la révision courante du paquet, et est utilisé par les programmes de maintenance des archives FTP Debian pour y installer les paquets binaires et sources. Il est partiellement généré à partir du fichier « changelog » et du fichier .dsc. Ce fichier est signé en PGP, de sorte que les gens peuvent être sûrs qu'il s'agit bien du vôtre.

Au fur et à mesure que vous travaillez sur le paquet, son comportement va changer et de nouvelles capacités seront ajoutées. Les gens qui téléchargent votre paquet peuvent lire ce fichier et voir rapidement ce qui a changé. Les programmes de maintenance des archives Debian vont aussi poster le contenu de ce fichier sur la liste de distribution debian-devel-change.

Les longues chaînes de chiffres dans les fichiers .dsc et .changes sont des sommes MD5 pour les fichiers mentionnés. Les personnes téléchargeant vos fichiers peuvent les tester avec et si les fichiers ne correspondent pas, ils sauront que le fichier a été corrompu ou qu'il a été piraté. Reconstruction rapide

Avec un paquet imposant, vous ne voudrez sans doute pas reconstruire depuis le début chaque fois que vous faites une petite modification à debian/rules. Pour tester, vous pouvez faire un fichier .deb sans reconstruire les sources amont comme ceci :

fakeroot debian/rules binary

Une fois que vous avez fini vos ajustements, souvenez-vous de reconstruire en suivant la procédure correcte ci-dessus. Vous pouvez ne pas être capable de télécharger correctement si vous essayez de télécharger des fichiers .deb construit comme ceci. Contrôler les erreurs du paquet

Lancez sur votre fichier .changes; ce programme va examiner un grand nombre d'erreurs de paquetage courantes. La commande est :

lintian -i gentoo_0.9.12-1_i386.changes

Bien sûr, remplacez le nom de fichier par celui du fichier .changes généré pour votre paquet. S'il s'avère qu'il y a des erreurs (les lignes commençant avec E:), lisez l'explication (les lignes N:), corrigez les erreurs, et reconstruisez comme décrit dans . S'il y a des lignes qui commencent avec W:, il s'agit de mises en garde, donc vous pouvez ajuster votre paquet ou vous assurer que les mises en garde sont inutiles (et faire en sorte que Lintian les ignore; voir la documentation pour les détails).

Remarquez que vous pouvez reconstruire le paquet avec .

Regardez dans votre paquet en utilisant un gestionnaire de fichiers comme ou décompressez-le dans une place temporaire en utilisant . Cherchez avant tout les fichiers inutiles, à la fois dans les paquets binaire et source. Souvent des crasses ne sont pas nettoyées correctement; ajustez votre fichier rules pour compenser. Astuce: `zgrep ^+++ ../gentoo_0.9.12-1.diff.gz` vous donnera la liste de vos modifications/additions au fichiers sources, et `dpkg-deb -c gentoo_0.9.12-1_i386.deb` la liste des fichiers dans le paquet.

Installez le paquet pour le tester vous-même, par exemple en utilisant en tant que root. Essayez de l'installer sur d'autres machines que la votre et vérifier attentivement chaque avertissement ou erreur tant à l'installation qu'en exécutant le programme. Envoyer votre paquet

Maintenant que vous avez testé votre nouveau paquet en détail, vous êtes prêt à commencer le processus d'application de nouveau responsable Debian, comme décrit dans .

Une fois que vous êtes devenu un responsable Debian officiel, vous devrez télécharger le paquet sur les archives Debian. Vous pouvez le faire manuellement, mais c'est plus facile d'utiliser les outils automatiques fournis, comme ou . Nous décrirons la façon de faire avec D'abord vous devez écrire le fichier de configuration de dupload. Vous pouvez soit éditer le fichier global /etc/dupload.conf, ou avoir votre propre fichier ~/.dupload pour remplacer les quelques détails que vous voulez changer. Mettez quelque chose comme ceci dans le fichier :

package config; $default_host = "ftp-master"; $cfg{"ftp-master"}{"login"} = "votrenomdebian"; $cfg{non-us}{"login"} = "votrenomdebian"; 1;

Bien sûr, remplacez mes informations personnelles par les vôtres, et lisez la page de manuel pour comprendre ce que chacune de ces options signifie.

L'option $default_host est la plus compliquée -- elle détermine quelle queue de téléchargement sera utilisée par défaut. « ftp-master » est la principale, mais il est possible que vous souhaitiez en utiliser une autre, plus rapide. Pour plus d'information sur les queues de téléchargement, lisez la Référence du Développeur, section « La mise à jour d'un paquet », dans /usr/share/doc/developers-reference/developers-reference.fr.html /ch-upload.fr.html#s-uploading.

Puis connectez-vous à votre fournisseur Internet et lancez cette commande :

dupload gentoo_0.9.12-1_i386.changes

et qu'il charge le fichier correctement.

Si vous téléchargez sur « ftp-master », Mettre à jour le paquet Nouvelle révision Debian

Disons qu'un rapport de bogue a été rempli pour votre paquet, #54321, et qu'il décrit un problème que vous pouvez résoudre. Pour créer une nouvelle révision du paquet, vous devez: Corriger le problème dans le paquet source, bien sûr. Ajouter une nouvelle révision au sommet du fichier changelog Debian, par exemple avec « dch -i », ou explicitement avec « dch -v <version>-<revision> », et ajoutez ensuite les commentaires en utilisant votre éditeur favori.

Astuce : comment obtenir facilement la date au format requis ? Utilisez « 822-date » ou « date -R ». Ajoutez une courte description du bogue et de la solution dans l'entrée du changelog, suivie par ceci : « Closes: #54321 ». De cette manière, le rapport de bogue sera automatiquement fermé par le logiciel de maintenance des archives au moment où votre paquet sera accepté dans l'archive Debian. Recommencez ce que vous aviez fait dans , , et . La différence est que cette fois, l'archive des sources originales ne sera pas inclue, car elle n'a pas été changée et est déjà dans l'archive Debian. Nouvelle version amont

Considérons maintenant une autre situation, légèrement plus compliquée - une nouvelle version amont est disponible, et bien sûr vous voulez en faire un paquet. Vous devez donc : télécharger les sources et mettre l'archive source (par exemple nommée `gentoo-0.9.13.tar.gz') dans le répertoire au dessus des anciennes sources (par exemple ~/debian/). Entrez dans le répertoire source ancien, et lancez: uupdate -u gentoo-0.9.13.tar.gz Bien sûr, remplacez le nom de fichier par celui de l'archive source de votre programme. va correctement renommer cette archive, essayer d'appliquer les modifications de votre précédent fichier .diff.gz, et mettre à jour le nouveau fichier debian/changelog. Allez dans le répertoire `../gentoo-0.9.13', l'arbre des sources du nouveau paquet, et recommencez ce que vous aviez fait dans , et .

Remarquez que si vous configurez `debian/watch' comme indiqué dans , vous pouvez lancer pour automagiquement chercher les nouvelles sources, les télécharger et exécuter Vérifier les mises à jour de paquet

Quand vous construisez une nouvelle version du paquet, vous devriez toujours suivre cette procédure pour vérifier que le paquet pour être tranquillement mis à jour : mettez à jour depuis la version précédente revenez à la version précédente, puis retirez-la installez le nouveau paquet retirez-le et réinstallez-le à nouveau purgez-le.

Gardez à l'esprit que si votre paquet a été livré avec Debian, les gens vont souvent mettre à jour votre paquet à partir de la révision qui était dans la dernière version Debian. Souvenez-vous de tester aussi les mises à jour à partir de cette révision. Où demander de l'aide

Avant de vous décider à poser une question dans un lieu public, s.v.p. RTFM. Ceci inclut la documentation sous /usr/share/doc/dpkg, /usr/share/doc/debian, /usr/share/doc/paquet/* et les pages de manuel/d'info pour tous les programmes mentionnés dans ce document.

Si vous avez des questions sur la création de paquets pour lesquelles vous n'avez pas pu trouver de réponses dans la documentation, vous pouvez les poser sur la liste de distribution Debian Mentor, at Consultez pour plus d'information sur cette liste de distribution.

Quand vous recevez un rapport de bogue (oui, un rapport de bogue réel!) vous saurez qu'il est temps de plonger dans le et lisez la documentation, pour être à même de gérer les rapports efficacement. Je recommande chaudement la lecture de la Référence du Développeur, chapitre « Gérer les bogues », dans /usr/share/doc/developers-reference/developers-reference.fr.html /ch-bug-handling.fr.html.

Si vous avez encore des questions, posez-les sur la liste de discussion Debian Developers à pour plus d'information sur cette liste de distribution.

Même si tout marche bien, il est temps de commencer à prier. Pourquoi ? Parce que dans quelques heures (ou jours) les utilisateurs du monde entier vont commencer à utiliser votre paquet, et si vous avec fait des erreurs critiques vous serez bombardé par les courriels d'utilisateurs Debian furieux... Je plaisante. :-)

Relaxez-vous et soyez prêt pour les rapports de bogues, parce qu'il y aura beaucoup plus de travail à faire avant que votre paquet soit parfaitement conforme aux règles Debian (une fois encore, lisez la documentation réelle pour les détails). Bonne chance !