Go to:
Gentoo Home
Documentation
Forums
Lists
Bugs
Planet
Store
Wiki
Get Gentoo!
Gentoo's Bugzilla – Attachment 45961 Details for
Bug 73654
[fr] new translation for devrel HB
Home
|
New
–
[Ex]
|
Browse
|
Search
|
Privacy Policy
|
[?]
|
Reports
|
Requests
|
Help
|
New Account
|
Log In
[x]
|
Forgot Password
Login:
[x]
gentoo-howto.xml
devrel-gentoo-howto.xml (text/plain), 86.09 KB, created by
Clément VARALDI
on 2004-12-14 03:17:31 UTC
(
hide
)
Description:
gentoo-howto.xml
Filename:
MIME Type:
Creator:
Clément VARALDI
Created:
2004-12-14 03:17:31 UTC
Size:
86.09 KB
patch
obsolete
><?xml version='1.0' encoding='UTF-8'?> ><!DOCTYPE sections SYSTEM "/dtd/book.dtd"> > ><!-- The content of this document is licensed under the CC-BY-SA license --> ><!-- See http://creativecommons.org/licenses/by-sa/1.0 --> > ><!-- This document was last synched to: > cvs://gentoo/gentoo/xml/htdocs/doc/en/gentoo-howto.xml :: R1.50. >--> > ><sections> > ><date>22-11-2004</date> > ><section> ><title>L'arbre de Portage</title> > > <subsection> > <title>Introduction</title> > <body> > <p> > L'arbre de Portage se trouve en général dans <path>/usr/portage</path> > et est organisé selon une structure hiérarchique constituée de > répertoires de catégories, suivis des répertoires spécifiques aux > paquets. Voici un exemple : vous pourrez trouver le fichier <path> > util-linux-2.11y.ebuild</path> dans le répertoire <path> > /usr/portage/sys-apps/util-linux</path>. Il peut y avoir plusieurs > autres versions d'ebuilds pour <c>util-linux</c> à côté de <path> > util-linux-2.11y.ebuild</path>. C'est dû au fait que <e>tous les ebuilds > pour un paquet particulier</e> (quelque soit la version) partagent le > même répertoire <path>ma_categorie/mon_paquet</path> dans <path> > /usr/portage</path>. > </p> > </body> > </subsection> > > > <subsection> > <title>Récupérer une version de l'arbre de Portage avec CVS</title> > <body> > <p> > Si vous n'êtes pas familié au fonctionnement de CVS, vous pouvez lire le > <uri link="http://www.gentoo.org/doc/en/cvs-tutorial.xml">tutoriel CVS > </uri> pour plus d'informations. > </p> > > <p> > L'arbre de Portage peut être trouvé dans le module <c>gentoo-x86</c> de > l'arbre de Gentoo Linux. Pour récupérer ce module (environ 350Mo), vous > devez tout d'abord préparer CVS, comme dit dans le guide cité plus haut, > puis récupérer le module <c>gentoo-x86</c>. > </p> > </body> > </subsection> > > > <subsection> > <title>Ce qu'on (ne) peut (pas) mettre dans l'arbre de Portage</title> > <body> > <p> > Avant d'écrire un ebuild, vérifiez sur <uri > link="http://bugs.gentoo.org/">bugs.gentoo.org</uri> s'il existe un > ebuild pour ce que vous voulez faire, mais qui n'a pas encore été mis > dans Portage. Allez sur <uri link="http://bugs.gentoo.org/"> > bugs.gentoo.org</uri>, choisissez <e>query</e>. Pour le produit, prenez > <e>Gentoo Linux</e>, et comme composant, <e>ebuilds</e>. Dans le champ > réservé à la recherche écrivez le nom de l'ebuild, puis comme statut, > selectionnez <e>NEW</e>, <e>ASSIGNED</e>, <e>REOPENED</e>, et <e> > RESOLVED</e> (<e>RESOLVED</e> est important ici), puis envoyez la > requête. Pour les fainéants, cliquez directement <uri link= > "http://bugs.gentoo.org/query.cgi?product=Gentoo%20Linux&component=Ebuilds&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED"> > ici</uri>. > </p> > > <p> > En règle générale, l'arbre de Portage ne doit être utilisé que pour > stocker des fichiers <path>.ebuild</path>, ainsi que divers fichiers qui > leur sont liés, comme par exemple les correctifs et des petits fichiers > de configuration. Ce genre de fichiers doit être placé dans le > répertoire <path>/usr/portage/macat/monpaquet/files</path> pour > garder garder une organisation des répertoires <path> > /macat/monpaquet</path> la plus propre et rangée possible. > Les exceptions à cette règle sont réservées aux correctifs de taille > importante, qui doivent être placés sur les miroirs Gentoo pour que les > utilisateurs ne perdent pas de bande passante inutile et d'espace disque > en les télechargeant. > De plus ce n'est en général pas une bonne idée d'ajouter des fichiers > binaires (non-ASCII) au CVS. Cependant, si vous devez le faire (par > exemple, si vous devez ajouter une petite image de type PNG pour une > raison quelconque, assurez-vous de l'ajouter au CVS en utilisant > l'option <c>-kb</c> comme suit : > </p> > > <pre caption="Ajouter un binaire au CVS"> ># <i>cvs add -kb monimage.png</i> > </pre> > > <p> > L'option <c>-kb</c> indique à CVS que <path>monimage.png</path> est un > fichier binaire et qu'il doit être traité de manière particulière. Par > exemple, lui adjoindre les différences entre deux versions de ce fichier > ne sera évidemment pas permis. De même, tant qu'on est sur le thème des > ajouts de modifications, tous les correctifs que vous ajoutez à Portage > devront <e>ne pas</e> être compressés. Cela permet à CVS de récupérer > les modifications, et d'informer les développeurs de conflits de manière > correcte. > </p> > > <p> > Souvenez-vous que les paquets que vous soumettez doivent être <e>prêts > </e> à l'utilisation de manière <e>autonome</e> s'ils sont soumis comme > étant stables. Assurez-vous que vous avez un bon environnement de > configuration, qui satisfasse le plus grand nombre de systèmes et > d'utilisateurs qui utiliseront votre paquet. Si votre paquet est cassé, > et que vous n'êtes pas sûr de comment faire pour le faire fonctionner, > regardez ce qu'ont fait d'autres distributions qui ont effectué leur > propres versions de ce paquet. Vous pouvez regarder chez <uri link= > "http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/SPECS/">Mandrake</uri> > ou <uri link="http://www.debian.org/distrib/packages">Debian</uri> pour > avoir de bons exemples. > </p> > > <p> > Re-vérifiez votre ebuild et vérifiez qu'il est bon en consultant la > section concernant les <uri link="?part=2&chap=3">Erreurs fréquentes > dans les ebuilds Gentoo</uri>. > </p> > > <p> > Quand ils effectuent une soumission au CVS, TOUS les développeurs > doivent utiliser <c>repoman commit</c> en lieu et place de <c>cvs commit > </c> pour soumettre leurs ebuilds. Avant de faire une soumission, vous > devez lancer un <c>repoman full</c> pour vous assurer que vous n'avez > rien oublié. > </p> > </body> > </subsection> > > > <subsection> > <title>Politique de soumission au CVS</title> > <body> > <ul> > <li>Toujours lancer <c>repoman scan</c> avant de soumettre son travail. > </li> > <li>Lancez <c>repoman full</c> avant de faire une soumission.</li> > <li>Toujours vérifier que <path>package.mask</path> est en règle en > effectuant un <c>emerge --pretend monpaquet</c> avant de le soumettre et > vérifiez qu'il n'y a aucun conflit.</li> > <li>Toujours mettre à jour le <path>ChangeLog</path> avant de faire une > soumission.</li> > <li>Toujours mettre à jour en premier <path>package.mask</path> avant de > ne mettre à jour le paquet concerné, il peut y avoir des conflits lors > de la soumission de <path>package.mask</path>.</li> > <li>Toujours faire des soumissions atomiques. Si vous soumettez un > paquet avec une nouvelle licence ou un paquet masqué, alors il vous > faudra tout d'abord soumettre la mise à jour de <path>package.mask > </path>, puis soumettre l'ebuild, le <path>ChangeLog</path> et la > licence, d'une traite, sauf si vous souhaitez corrompre les > installations des utilisateurs...</li> > </ul> > </body> > </subsection> > > > <subsection> > <title>Le répertoire pour les fichiers.</title> > <body> > <p> > Comme remarqué précédemment, dans chaque sous-répertoire de paquet, il y > a un répertoire <path>files/</path>. Tous les correctifs, fichiers de > configuration, et tous les fichiers annexes à votre paquet doivent être > placés dans ce répertoire. Vous aurez probablement à vous poser la > question de comment nommer un correctif que vous avez vous-même créé, > simplement pour que votre paquet puisse compiler avec un nom de version > spécifique. Il vous faudra alors le nommer par exemple <path> > monpaquet-1.0-gentoo.diff</path>, ou plus simplement <path> > 1.0-gentoo.diff</path>. Remarquez la présence de l'extension <path> > gentoo</path> qui indique aux utilisateurs que ce correctif a été créé > par nous, développeurs pour Gentoo Linux, et n'a donc pas été récupéré > sur une liste de diffusion ou ailleurs. Encore une fois, ne compressez > pas les fichiers diffs, car CVS n'est pas très bon dans la gestion des > fichiers binaires. > </p> > > <p> > Préfixez ou suffixez (comme par exemple <path>monpaquet-1.0</path>) tous > les fichiers que vous mettez dans le répertoire <path>files/</path>, > afin que les fichiers utilisés pour chaque version d'un ebuild soit > différenciable les uns des autres, et que les changements entre les > différentes révisions soient visibles. C'est en général une très bonne > idée. Vous pouvez également utiliser un autre suffixe si vous voulez > donner plus de sens au nom du correctif. > </p> > > <p> > S'il y a plusieurs fichiers qui doivent aller dans le répertoire <path> > files/</path>, vous pouvez créer des sous-répertoires comme par exemple > <path>files/1.0/</path> et mettre les fichiers en question dans le bon > sous-répertoire. Si vous utilisez cette méthode, vous n'avez pas besoin > d'indiquer plus d'informations dans le nom des fichiers, ce qui est > d'ailleurs ce qui se fait en général, c'est plus commode. > </p> > </body> > </subsection> ></section> > > > > ><section> ><title>Scripts ebuild</title> > <subsection> > <title>Introduction</title> > <body> > <p> > Les scripts d'ebuild sont la base de l'intégralité du système de > Portage. Ils contiennent toutes les informations nécessaires pour > télécharger, désarchiver, compiler et installer un ensemble de sources, > ainsi que les informations nécessaires pour réaliser n'importe quelle > tache de pre/post installation/suppression ou de configuration. Si la > majeure partie de Portage est écrite en Python, les scripts ebuild sont, > eux, écrits en bash, dans la mesure où bash nous permet d'appeler des > commandes comme si elles étaient appelées depuis un invite de commande. > Un des principes importants dans la conception, que l'on retrouve > derrière les scripts ebuild, c'est d'avoir des commandes dans le script > qui sont analogues à celles que l'on taperait dans une console si l'on > installait le paquet manuellement. Pour cela, utiliser une syntaxe bash > est une vraiment bonne chose. > </p> > > <p> > Les scripts ebuild sont interprétés par les commandes <c>ebuild</c> et > <c>emerge</c>. Il faut imaginer la commande <c>ebuild</c> comme un > outil de bas niveau. Il peut construire et installer un simple ebuild, > mais pas plus. Il vérifiera si les dépendances sont satisfaites, mais il > n'essayera pas de les résoudre automatiquement lui-même. D'un autre côté > <c>emerge</c> est un outil de haut niveau pour <c>ebuild</c>, et il a la > capacité d'installer automatiquement les dépendances si elles sont > nécessaires, d'effectuer des vérifications d'installation (avec <e> > pretend</e>) pour que l'utilisateur puisse voir quels sont les ebuilds > qui seront installés et s'arrêter là . En général, <c>emerge</c> vole la > vedette à <c>ebuild</c> dans tous les domaines, sauf un. Avec <c>ebuild > </c>, vous pouvez effectuer les étapes les unes après les autres lors > de l'installation d'un paquet (récupération des sources, désarchivage, > compilation, installation, et fusion dans Portage). Pour les > développeurs, c'est un outil de correction d'erreur précieux, car il > vous permettra d'isoler les problèmes d'un ebuild par parties > spécifiques dans l'ebuild. > </p> > </body> > </subsection> > > > <subsection> > <title>Nommer les fichiers ebuild</title> > <body> > <p> > Les noms de fichiers ebuild sont constitués de quatre parties > logiques : > </p> > > <p> > La première partie est le nom du paquet, qui ne doit contenir que des > lettres minuscules, des nombres entre 0 et 9, et les caractères trait > d'union ('-'), soulignement ('_'), ou plus ('+'). Par exemple, > <c>util-linux</c>, <c>sysklogd</c>, <c>mod_php</c> et <c>gtk+</c>. > </p> > > <p> > La seconde partie est la version du paquet, qui est en général la même > que la version de l'archive source principale. La version est en général > composée de deux ou trois nombres séparés par un point, comme <c>1.2</c> > ou <c>4.5.2</c> (cependant des séquences plus longues sont supportées), > et peut avoir une lettre seule, qui suit le dernier chiffre ; par > exemple <c>1.4b</c> ou <c>2.6h</c>. La version du paquet est liée au nom > du paquet par un trait d'union. Par exemple, <c>foo-1.0</c> ou <c> > bar-2.4.6</c>, etc. > </p> > > <impo> > Si vous pensez utiliser une lettre en queue de la version du paquet, > n'oubliez pas que ce caractère <e>ne doit pas</e> être utilisé pour > signifier le statut alpha ou beta d'un paquet, dans la mesure ou les > alphas et betas sont des <e>pré-sorties</e> et les révisions ultérieures > sont des <e>nouvelles versions</e>. C'est une distinction importante, > car Portage utilise le numéro de version des ebuilds pour déterminer si > il est plus récent ou plus vieux que les autres paquets d'une même > catégorie et d'un même nom. C'est très important d'avoir des noms de > version représentant fidèlement la version du paquet, afin que Portage > puisse vérifier correctement les dépendances entre les paquets. > </impo> > > <p> > La troisième partie (optionnelle) contient un suffixe spécial : > au choix <c>_alpha</c>, <c>_beta</c>, <c>_pre</c> (pré-sortie), <c>_rc > </c> (candidat à une sortie) ou <c>_p</c> (correctif). Ils sont toujours > suivi directement d'un nombre. Par exemple, <c>linux-2.4.0_pre10</c>. > Pour une version identique (voir la deuxième partie du nom d'un ebuild), > un paquet <c>_alpha</c> est plus vieux qu'un <c>_beta</c>, un <c>_beta > </c> est plus vieux qu'un <c>_pre</c>, un <c>_pre</c> est plus vieux > qu'un <c>_rc</c>, et un <c>_rc</c> est plus vieux que le même paquet > sans suffixe. Un paquet sans suffixe est plus vieux qu'un paquet avec > <c>_p</c>. Cette partie est utilisée uniquement pour signaler une > mise à jour dans une même version. > </p> > > <note> > Un paquet <c>_rc</c> est plus vieux qu'un paquet sans suffixe avec > soulignement (par exemple <c>linux-2.4.0</c>), et <c>linux-2.4.0</c> > est plus vieux qu'un paquet avec un suffixe à une seule lettre, par > exemple <c>linux-2.4.0b</c>. Comme vous vous y attendez, le paquet > <c>linux-2.4.0b</c> est considéré comme plus vieux que <c>linux-2.4.0c > </c>. Encore une fois, les informations sur la version sont importantes, > car Portage les utilise de manière interne pour déterminer si un paquet > ou un ebuild est plus récent qu'un autre, pour une catégorie et un nom > donnés. > </note> > > <p> > La quatrième partie (encore optionnelle) d'un nom de paquet est le > numéro de <e>révision</e> spécifique à Gentoo, qui est spécifié par un > <c>-r#</c>, où <c>#</c> est un entier, par exemple <c>paquet-4.5.3-r3 > </c>. Ce numéro de révision est indépendant de la version de l'archive > source, et est utilisé pour informer les utilisateurs qu'une nouvelle > révision ou amélioration de la part de Gentoo est disponible pour un > certain paquet. > </p> > > <p> > Si vous faites des amélioratons non triviales dans un fichier ebuild > déjà existant, vous devez copier le fichier ebuild dans un nouveau > fichier, avec un numéro de révirion incrémenté de 1. Les sorties > initiales n'ont en général pas de numéro de révision, par exemple > <path>paquet-4.5.3</path>, et sont considérés par Portage comme ayant un > numéro de révision de 0. Cela signifie que le décompte se fait comme > suit : <c>1.0</c> (version initiale), <c>1.0-r1</c>, <c>1.0-r2</c>, > etc. N'outliez <e>jamais</e> de laisser une mention de vos modifications > dans le <path>ChangeLog</path>, vous pourriez avoir de sérieux problèmes > si vous ne le faites pas (par exemple votre accès CVS pourrait être > révoqué). > </p> > > <p> > Et évidemment nous avons une cinquiète partie dans le nom de l'ebuild... > l'extension <c>.ebuild</c> elle-même. > </p> > </body> > </subsection> > > > > <subsection> > <title>Le contenu d'un fichier ebuild</title> > <body> > <note> > Cette partie est une introduction aux ebuilds. Pour une liste complète > de toutes les possibilités d'un ebuild, il existe une page de manuel qui > détaille le format interne, les variables, et les fonctions qu'on peut > trouver dans un script ebuild :<c>man 5 ebuild</c>. > </note> > > <p><b>Les variables</b></p> > > <p> > La première partie de tous les fichiers ebuild est constituée d'un > certain nombre de variables. Elles sont placées dans trois catégories > qui sont : > </p> > > <ul> > <li>READ : les variablesque vous pouvez utiliser mais qui ne > <e>sont jamais déclarées</e>.</li> > <li>MUST : les variables que vous devez <e>toujours déclarer</e>.</li> > <li>OPT : les variables que vous pouvez déclarer.</li> > </ul> > > <table> > <tr> > <th>Variable</th> > <th>Utilisation</th> > <th>Description</th> > </tr> > > <tr> > <ti><c>P</c></ti> > <ti>READ</ti> > <ti>Le nom et la version du paquet.</ti> > </tr> > > <tr> > <ti><c>PN</c></ti> > <ti>READ</ti> > <ti>Le nom du paquet.</ti> > </tr> > > <tr> > <ti><c>PV</c></ti> > <ti>READ</ti> > <ti>La version du paquet.</ti> > </tr> > > <tr> > <ti><c>PR</c></ti> > <ti>READ</ti> > <ti>Contient le numéro de révision ou <c>r0</c> si aucun numéro de > révision n'existe.</ti> > </tr> > > <tr> > <ti><c>PVR</c></ti> > <ti>READ</ti> > <ti>Contient le numéro de version avec la révision.</ti> > </tr> > > <tr> > <ti><c>PF</c></ti> > <ti>READ</ti> > <ti>Contient le nom complet du paquet <c>${PN}-${PVR}</c>.</ti> > </tr> > > <tr> > <ti><c>A</c></ti> > <ti>READ</ti> > <ti>Liste séparée par des espaces, des fichiers dans <c>SRC_URI</c>. > Elle ne contient pas les directions URL, juste le nom de fichier. > </ti> > </tr> > > <tr> > <ti><c>DISTDIR</c></ti> > <ti>READ</ti> > <ti>Contient la direction du répertoire <path>distfiles</path> où tous > les fichiers récupérés pour un paquet sont mis. C'est en général > <path>/usr/portage/distfiles</path>. > </ti> > </tr> > > <tr> > <ti><c>FILESDIR</c></ti> > <ti>READ</ti> > <ti>Contient la direction vers le sous-répertoire <path>files/</path> > dans l'emplacement spécifique du paquet dans l'arbre de Portage. > Ne modifiez pas cette variable. > </ti> > </tr> > > <tr> > <ti><c>WORKDIR</c></ti> > <ti>READ</ti> > <ti>Base de la racine de travail pour un ebuild. Rien ne doit être > construit hors de ce répertoire. > </ti> > </tr> > > <tr> > <ti><c>S</c></ti> > <ti>OPT</ti> > <ti>Le répertoire source pour votre paquet : en général, <c> > ${WORKDIR}/${P}</c>. Portage va prendre cette valeur par défaut > donc vous n'avez probablement pas besoin de l'initialiser. > </ti> > </tr> > > <tr> > <ti><c>T</c></ti> > <ti>READ</ti> > <ti>Le répertoire temporaire pour votre paquet. Il est utilisé comme > un répertoire <path>/tmp</path> virtuel lors de l'exécution de > l'ebuild. > </ti> > </tr> > > <tr> > <ti><c>D</c></ti> > <ti>READ</ti> > <ti>Le répertoire racine où le paquet devra être installé. > Considérez-le comme un <path>/</path> virtuel. > </ti> > </tr> > > <tr> > <ti><c>SLOT</c></ti> > <ti>MUST</ti> > <ti>Portage manipule souvent plusieurs versions d'un même programme > installé. Par exemple vous pouvez avoie GCC 2.95 et GCC 3.2 > installés en même temps sur votre machine. Vous devez alors > spécifier le <c>SLOT</c> dans chaque ebuild. Ici nous prendrions > pour le <c>SLOT</c> de GCC 2.95 un <c>2</c> alors que nous aurions > un <c>3</c> pour le <c>SLOT</c> de GCC 3.2. > <br/> > <b>Note</b> : utiliser <c>0</c> comme valeur du <c>SLOT</c> > signifie que le paquet n'a qu'un seul <c>SLOT</c> possible (en > d'autres termes, ce paquet n'est pas "SLOTable"). > </ti> > </tr> > > <tr> > <ti><c>LICENSE</c></ti> > <ti>MUST</ti> > <ti>Cette variable spécifie sous quelle licence est le programme, > c'est à dire GPL-2, BSD, etc. Ce champ doit être initialisé à une > valeur de licence valide (qui peut être n'importe quelle licence > dans le répertoire <path>/usr/portage/license/</path>). Si la > licence n'y est pas encore répertoriée, elle doit être ajoutée > avant que l'ebuild ne soit ajoutée à l'arbre de Portage. > </ti> > </tr> > > <tr> > <ti><c>KEYWORDS</c></ti> > <ti>MUST</ti> > <ti>Cette variable remplie désormais un certain nombre de fonctions. > Tout d'abord, elle spécifie la cibles de l'ebuild en matière > d'architecture. Les mots-clefs incluent : <e>x86, ppc, sparc, > mips, alpha, arm, hppa, amd64, ia64</e> (NdT : cette liste > n'est plus complète actuellement, de nouveaux mots-clefs ont été > ajoutés récemment). Ãvidemment, vous utiliserez ceci pour indiquer > l'architecture de la machine cible. Portage n'autorisera pas une > machine x86 à construire autre chose que des ebuilds dont le > mot-clef x86 est spécifié dans la variable <c>KEYWORDS</c>. Les > paquets qui ne supportent pas une architecture nativement, sont > automatiquement masqués par Portage. Si le paramètre <c> > KEYWORDS</c> est précédé d'un <e>~</e>, alors cela indique que > l'ebuild fonctionne, mais nécessite encore plusieurs tests dans > différents environnements avant d'être placé dans un profile > stable avec le mot-clef associé. Si rien ne précède le > <c>KEYWORDS</c> alors le paquet est considéré comme stable. > Vous pouvez autoriser l'installation de ces différents types > de paquets à travers l'utilisation de la variable <c> > ACCEPT_KEYWORDS</c> dans <path>make.conf</path>, ou dans le > fichier <path>/etc/portage/package.keywords</path>. > </ti> > </tr> > > <tr> > <ti><c>DESCRIPTION</c></ti> > <ti>MUST</ti> > <ti>Une <e>courte</e> et unique ligne de description de votre paquet. > </ti> > </tr> > > <tr> > <ti><c>SRC_URI</c></ti> > <ti>MUST</ti> > <ti>Les URLs pour chaque fichier source de votre paquet, en les > séparant d'un espace. Normalement, le premier devrait ressembler à > "ftp://ftp.compagnie.com/pub/unpaquet/${P}.tar.bz2" > </ti> > </tr> > > <tr> > <ti><c>HOMEPAGE</c></ti> > <ti>MUST</ti> > <ti>La page Internet dédiée au paquet. Si vous n'arrivez pas à trouver > la page officielle, essayez de trouver un lien depuis le site <uri > link="http://freshmeat.net/">freshmeat.net</uri> ou un site de > traçage de paquet similaire. > </ti> > </tr> > > <tr> > <ti><c>IUSE</c></ti> > <ti>MUST</ti> > <ti>Cette variable contient les paramètres <c>USE</c> que votre paquet > utilise. Souvenez-vous que <c>KEYWORDS</c> ne doit pas y être > listé ! > </ti> > </tr> > > <tr> > <ti><c>DEPEND</c></ti> > <ti>OPT</ti> > <ti>Les dépendances de construction du paquet sont listées ici. Lire > la section sur les <uri link="#doc_chap5">dépendances de paquets > </uri> pour plus de détails sur la syntaxe. > </ti> > </tr> > > <tr> > <ti><c>RDEPEND</c></ti> > <ti>OPT</ti> > <ti>Les dépendances d'exécution du paquet sont listées ici. Encore une > fois lire la section sur les <uri link="#doc_chap5">dépendances de > paquets</uri> pour plus de détails sur la syntaxe. > </ti> > </tr> > </table> > > <p><b>Les fonctions</b></p> > > <p> > Il existe un certain nombre de différentes fonctions que vous pouvez > définir dans vos fichiers ebuilds, qui contrôlent la construction et > le processus d'installation de votre paquet. > </p> > > <table> > <tr> > <th>Fonction</th> > <th>Objectif</th> > </tr> > > <tr> > <ti><c>pkg_setup</c></ti> > <ti>Utilisez cette fonction pour effectuer n'importe quel type de > tache qui sont des prérequis à la construction. Cela inclue la > vérification de l'existence d'un fichier de configuration par > exemple. S'il est nécessaire de créer des utilisateurs ici, vous > devez également faire une vérification dans la fonction <c> > pkg_preinst()</c> avant que le paquet ne s'installe. > </ti> > </tr> > > <tr> > <ti><c>pkg_nofetch</c></ti> > <ti>Informe l'utilisateur des actions requises si pour une raison ou > pour une autre (comme par exemple des conditions liées à la > licence) les sources ne serait pas téléchargeable automatiquement > par Portage lors du processus normal d'installation. Utilisez-le > en conjonction avec <c>RESTRICT="fetch"</c>. Vous ne > devez que faire un affichage de messages avec cette fonction, > jamais d'appel à la fonction <c>die</c>. > </ti> > </tr> > > <tr> > <ti><c>src_unpack</c></ti> > <ti>Utilisez cette fonction pour désarchiver les sources, les > correctifs et pour lancer des programmes auxiliaires, comme par > exemple autotools. Par défaut, cette fonction désarchive les > paquets listés dans <c>A</c>. Le répertoire de travail initial est > défini par <c>WORKDIR</c>. > </ti> > </tr> > > <tr> > <ti><c>src_compile</c></ti> > <ti>Utilisez cette fonction pour configurer et construire le paquet. > Le répertoire initial de travail est <c>S</c>. > </ti> > </tr> > > <tr> > <ti><c>src_install</c></ti> > <ti>Utilisez cette fonction pour installer le paquet dans une image > dans <c>D</c>. Si le paquet utilise automake, vous pouvez > simplement effectuer un <c>make DESTDIR=${D} install</c>. > <e>Assurez-vous que votre paquet installe tous ses fichiers en > utilisans <c>D</c> comme racine !</e> Le répertoire initial > de travail est <c>S</c>. > </ti> > </tr> > > <tr> > <ti><c>src_test</c></ti> > <ti>Exécuté uniquement quand vous avez fait un <c>FEATURES="maketest" > </c> et que <c>RESTRICT="maketest"</c> n'est pas mis, la fonction > par défaut exécutera une fonction de test disponible dans > n'importe quel Makefiles dans le répertoire <c>${C}</c>, en > lançant au choix "make test" ou "make check", selon la fonction > disponible. Ce comportement par défaut peut être remplacé par une > fonction de test faite sur mesure. > </ti> > </tr> > > <tr> > <ti><c>pkg_preinst</c></ti> > <ti>Les commandes dans cette fonction sont lancées juste <e>avant la > fusion</e> de l'image du paquet dans le système de fichier. > </ti> > </tr> > > <tr> > <ti><c>pkg_postinst</c></ti> > <ti>Les commandes dans cette fonction sont lancées juste <e>après la > fusion</e> de votre image de paquet dans le système de fichier. > </ti> > </tr> > > <tr> > <ti><c>pkg_prerm</c></ti> > <ti>Les commandes dans cette fonction sont lancées juste <e>avant la > suppression</e> d'un paquet du système de fichier. > </ti> > </tr> > > <tr> > <ti><c>pkg_postrm</c></ti> > <ti>Les commandes dans cette fonction sont lancées juste <e>après la > suppression</e> d'un paquet du système de fichier. > </ti> > </tr> > > <tr> > <ti><c>pkg_config</c></ti> > <ti>Vous utiliserez cette fonction pour mettre en oeuvre une > configuration initiale d'un paquet après qu'il ait été installé. > Toutes les directions de répertoire dans cette fonction doivent > être préfixées de <c>ROOT</c>. Cette fonction n'est <e>uniquement > </e> exécutée que si l'utilisateur lance : <c>ebuild > /var/db/pkg/${CATEGORY}/${PF}/${PF}.ebuild config</c>. > </ti> > </tr> > </table> > > > <p><b>Les fonctions d'aide</b></p> > > <p> > Vous pouvez également utiliser les fonctions d'aide suivantes dans vos > ebuilds. > </p> > > <table> > <tr> > <th>Fonction</th> > <th>Objectif</th> > </tr> > > <tr> > <ti><c>use</c></ti> > <ti>Vérifier si un ou plus des paramètres USE sont définis. Si c'est > le cas, la fonction retournera les paramètres qui existent dans > <c>USE</c>. Cette possibilité va bientôt être modifiée, et <c> > use</c> ne retournera rien, mais <c>usev</c> continuera à > retourner les paramètres. Pour vérifier l'existence d'un paramètre > USE, vous pouvez utiliser <c>use foorbar</c>. > </ti> > </tr> > > <tr> > <ti><c>has_version</c></ti> > <ti>Retourne 1 si le système a la version requise d'un certain paquet. > Utilisez-le ainsi : <c>has_version >=sys-libs/glibc-2.3.0 > </c>. > </ti> > </tr> > > <tr> > <ti><c>best_version</c></ti> > <ti>Retourne le couple <path>categorie/paquet-version</path> d'un > <path>categorie/paquet</path> demandé. Utilisez-le ainsi : > <c>best_version x11-libs/gtk+extra</c>. > </ti> > </tr> > > <tr> > <ti><c>use_with</c></ti> > <ti>Cette fonction vérifie si un paramètre USE a été défini, et > retourne "--with-foobar" ou "--without-foobar" > selon le cas. Si vous ne donnez qu'un seul argument, cet argument > sera à la fois paramètre USE et with(out)-string. Sinon le premier > argument sera le paramètre USE, et le second sera le with(out)- > string. Par exemple, <c>use_with truetype freetype</c> retournera > "--with-freetype" si truetype est dans les <c>USE</c>. > </ti> > </tr> > > <tr> > <ti><c>use_enable</c></ti> > <ti>La même chose que <c>use_with</c>, mais retourne > "--enable-foobar" ou "--disable-foobar" selon > le cas. > </ti> > </tr> > > <tr> > <ti><c>check_KV</c></ti> > <ti>Vérifie si Portage connait la version du noyau. Si non, cette > fonction retourne une erreur et meurt. Si vous avez besoin d'une > version de noyau dans votre script, utilisez la variable<c>KV</c> > qui est automatiquement définie par Portage. Sur un système > utilisant gentoo-sources-2.4.20-r6, <c>KV</c> devra avoir la > valeur "2.4.20". > </ti> > </tr> > > <tr> > <ti><c>keepdir</c></ti> > <ti>Crèe (si besoin) un fichier <path>.keep</path> dans le répertoire > donné, afin qu'il ne soit pas supprimé automatiquement. Ne <e> > jamais</e> créer de fichier <path>.keep</path> soi-même. Si > Portage change le fonctionnement de <c>keepdir</c>, alors créer un > tel fichier vous-même pourrait casser le paquet. > </ti> > </tr> > > <tr> > <ti><c>econf</c></ti> > <ti>Effectue <c>./configure</c> avec les changements de répertoires > nécessaires (prefix, host, mandir, infodir, datadir, sysconfdir, > localstatedir). Vous pouvez optionnellement lui passer des > arguments supplémentaires pour <c>./configure</c> en les donnant > lors de l'appel d'<c>econf</c>, et les utilisateurs peuvent > utiliser également la variable <c>EXTRA_ECONF</c> si ils en ont > besoin. Les options passées à configure sont passées dans l'ordre > inverse à celui dans lequel elles ont été données. En d'autres > termes, le premier argument passé sera toujours remplacé par le > dernier. > </ti> > </tr> > > <tr> > <ti><c>einstall</c></ti> > <ti>Effectue un <c>make install</c> avec les bons changements de > répertoires (prefix, host, mandir, infodir, datadir, sysconfdir, > localstatedir).Encore une fois, vous pouvez donner des arguments > supplémentaires à la commande make en les donnant directement > comme paramètres à <c>einstall</c>. Notez que la manière utilisée > de manière préférentielle pour installer un paquet est d'utiliser > la commande <c>make install DESTDIR=${D}</c> et non <c>einstall > </c>. Cette commande n'est qu'un moyen pour écrire par dessus un > fichier make cassé. > </ti> > </tr> > > <tr> > <ti><c>die</c></ti> > <ti>Avorte le processus en cours. Il indiquera à l'utilisateur > les données passées en argument, comme une raison d'avortement. > Ne pas négliger l'utilisation de message à <c>die</c> si vous > faites plusieurs appels à <c>die</c> dans une même fonction. > Il sera plus dur de rechercher une erreur si vous n'êtes pas sûr > de savoir <e>où</e> le paquet a échoué. > </ti> > </tr> > > <tr> > <ti><c>einfo</c></ti> > <ti>Informe l'utilisateur d'un événement important. L'argument passé à > <c>einfo</c> est le message qui sera passé à l'utilisateur. > N'utilisez pas <c>einfo</c> pour afficher des bannières comme > "*************************************". Le fait même > d'utiliser <c>einfo</c> est suffisant pour attirer l'attention de > l'utilisateur. > </ti> > </tr> > </table> > > <p><b>Fonctions d'aide proposées par eutils.eclass</b></p> > > <p> > Vous pouvez utiliser les fonctions d'aide suivantes, qui sont proposées > par l'eclass "eutils" de vos ebuilds. Vous devez vous assurer que <c> > inherit eutils</c> est présent pour que vous puissiez utiliser ces > fonctions. > </p> > > <table> > <tr> > <th>Fonction</th> > <th>Objectif</th> > </tr> > > <tr> > <ti><c>draw_line</c></ti> > <ti>Cette fonction affiche une liste de '=' ayant la longueur de > l'entrée de la fonction. > </ti> > </tr> > > <tr> > <ti><c>epatch</c></ti> > <ti>Cette fonction ressemble un peu à la commande <c>patch</c>mais a > l'avantage de fonctionner avec des correctifs aux formats .bz2, > .gz, .zip et fichier texte. Vous n'avez pas besoin de lui > spécifier une option "-p", toutes les options qui ont besoin > d'être passées de manière explicite à la fonction doivent être > mises dans <c>EPATCH_OPTS</c>. La fonction prend pour argument > soit un fichier, soit un répertoire -si vous lui donnez un > répertoire, tous les correctifs de la forme "??_${ARCH}_..." > seront appliqués. Pour qu'un correctif soit appliqué, il doit > correspondre à l'architecture spécifiée, ou avoir "_all_" dans son > nom (pour toutes les supporter) ou initialiser <c>EPATCH_FORCE</c> > à "yes". > </ti> > </tr> > > <tr> > <ti><c>gen_usr_ldscript</c></ti> > <ti>Cette fonction génère des scripts de liens dans <path>/usr/lib > </path> pour les bibliothèques dynamiques dans <path>/lib</path>. > Cela résoud les problèmes de liens, lorsqu'un .so est dans <path> > /lib</path> alors qu'un .a est dans <path>/usr/lib</path>. > </ti> > </tr> > > <tr> > <ti><c>have_NPTL</c></ti> > <ti>Retourne 0 si le système utilise l'implémentation des pthreads > NPTL. > </ti> > </tr> > > <tr> > <ti><c>get_number_of_jobs</c></ti> > <ti>Cette fonction vérifie le nombre de CPUs présents et ajoute dans > <c>MAKEOPTS</c> l'option correcte -jX correspondante. > </ti> > </tr> > > <tr> > <ti><c>mymktemp</c></ti> > <ti>Cette fonction agit comme un "wrapper" à mktemp quand il existe, > ou agit comme un remplacement à cette fonction quand elle n'existe > pas. > </ti> > </tr> > > <tr> > <ti><c>edos2unix</c></ti> > <ti>Cette fonction effectue le même travail que le binaire <c> > dos2unix</c>. > </ti> > </tr> > > <tr> > <ti><c>egetent</c></ti> > <ti>egetent agit comme un wrapper pour <c>getent</c> pour Linux, ou > <c>nidump</c> pour Mac OS X (R). > </ti> > </tr> > > <tr> > <ti><c>enewuser</c></ti> > <ti>Crèe un nouvel utilisateur. Cette fonction prend pour argument > obligatoire le nom d'utilisateur, et un certain nombre d'arguments > optionnels peuvent lui être spécifiés : <c>$2</c> contient > un UID. Mettre -1 pour qu'il prenne la prochaine ID disponible. > <c>$3</c> contient un shell, avec <path>/bin/false</path> comme > shell par défaut. <c>$4</c> contient le répertoire utilisateur, > avec <path>/dev/null</path> comme répertoire par défaut. <c>$5</c> > contient tous les groupes auquel l'utilisateur doit être ajouté, > vide par défaut, et <c>$6</c> contient un commentaire. Par défaut, > le commentaire sera "added by portage for <c>${PN}</c>". > </ti> > </tr> > > <tr> > <ti><c>enewgroup</c></ti> > <ti>Ajoute un nouveau groupe. Cette fonction prend pour paramètre > obligatoirement le nom du groupe, et comme paramètre optionnel, on > peut lui indiquer le GID souhaité pour ce groupe. > </ti> > </tr> > > <tr> > <ti><c>make_desktop_entry</c></ti> > <ti>Crèe une entrée de bureau : le premier argument contient > le répertoire qui mène au binaire. De manière optionnelle le > second argument contient le nom pour l'icône -par défaut, <c>${PN} > </c> ; le troisième argument peut contenir la direction d'une > icône à partir de <path>/usr/share/pixmaps</path> ou en donnant la > direction complète à partir de la racine -par défaut, > <c>${PN}</c>.png ; le quatrième peut contenir une <uri link= > "http://www.freedesktop.org/standards/menu-spec/">catégorie > d'application</uri>, et enfin le cinquième argument contient la > direction (optionnel) de lancement de l'application. > </ti> > </tr> > > <tr> > <ti><c>check_license</c></ti> > <ti>Affiche une licence que l'utilisateur devra accepter. Si aucun > argument n'est donné à la fonction, la licence spécifiée sera > celle donnée par <c>${LICENSE}</c>. > </ti> > </tr> > > <tr> > <ti><c>unpack_pdv</c></ti> > <ti>Désarchive une archive générée avec pdv. Le premier argument doit > contenir le fichier à désarchiver, et le second devrait contenir > "off_t" qui doit être généré manuellement :<c>strace -elseek > ${file}</c> et pour obtenir quelque chose du genre "lseek(3, -4, > SEEK_END)" vous devriez lui passer comme valeur "4". > </ti> > </tr> > > <tr> > <ti><c>unpack_makeself</c></ti> > <ti>Désarchive une archive créée avec makeself. L'argument nécessaire > sera le nom du fichier à désarchiver. > </ti> > </tr> > > <tr> > <ti><c>cdrom_get_cds</c></ti> > <ti>Essaye d'obtenir un CD, qui possède les fichiers spécifiés en > argument, et qui est monté sur <c>${CDROM_ROOT}</c>. > </ti> > </tr> > > <tr> > <ti><c>cdrom_load_next_cd</c></ti> > <ti>Charge le CD suivant une fois que vous en avez fini avec le > premier CD. Si la fonction est lancée, <c>${CDROM_ROOT}</c> devra > pointer vers le CD suivant. > </ti> > </tr> > > <tr> > <ti><c>strip-linguas</c></ti> > <ti>Cette fonction s'assure que LINGUAS contienne uniquement les > langues que le paquet peut supporter, spécifées en arguments à la > fonction. Si le premier argument est -i, alors la liste des > fichiers .po dans les répertoires spécifiés est construite et la > conjonction des deux listes présentes est utilisée. Si en premier > argument est donné -u, alors la liste des fichiers .po des > répertoires spécifiés est construite et l'union des listes est > utilisée. > </ti> > </tr> > </table> > > <p><b>Fonctions d'aide proposées par flag-o-matic.eclass</b></p> > > <p> > Vous pouvez utiliser les fonctions d'aide suivantes, qui sont proposées > par l'eclass "flag-o-matic" dans vos ebuilds. Vous devez vous assurer > que <c>inherit flag-o-matic</c> est présent pour que ces fonctions > puissent fonctionner. Vous ne devez pas modifier les configurations des > compilateurs directement, à la place, utilisez flag-o-matic pour > effectuer toutes les actions, comme par exemple filtrer les paramètres > qui posent problème. > </p> > > <table> > <tr> > <th>Fonction</th> > <th>Objectif</th> > </tr> > > <tr> > <ti><c>filter-flags</c></ti> > <ti>Cette fonction supprime un paramètre particulier de <c>C[XX]FLAGS > </c> seuls les paramètres complets sont vérifiés. > </ti> > </tr> > > <tr> > <ti><c>append-flags</c></ti> > <ti>Cette fonction ajoute un paramètre supplémentaire à ceux définis > dans les variables <c>C[XX]FLAGS</c>. > </ti> > </tr> > > <tr> > <ti><c>replace-flags</c></ti> > <ti>Celle-ci remplace un paramètre spécifié en premier argument par > un autre, donné en second argument, dans les variables actuelles de > <c>C[XX]FLAGS</c>. > </ti> > </tr> > > <tr> > <ti><c>replace-cpu-flags</c></ti> > <ti>Remplace tous les paramètres -march=... ou -mcpu=... qui > contiennent le second argument, par le premier. > </ti> > </tr> > > <tr> > <ti><c>replace-sparc64-flags</c></ti> > <ti>Cette fonction établi le paramètre -mcpu=... pour les SPARC v8 et > utilise la valeur d'origine pour -mtune, si aucune valeur n'est > encore spécifiée ici. > </ti> > </tr> > > <tr> > <ti><c>strip-flags</c></ti> > <ti>Enlève tous les paramètres, sauf ceux spécifiés dans <c> > ALLOWED_FLAGS</c>. > </ti> > </tr> > > <tr> > <ti><c>strip-unsupported-flags</c></ti> > <ti>Enlève de <c>C[XX]FLAGS</c> tous les paramètres non supportés par > la version utilisée de GCC. > </ti> > </tr> > > <tr> > <ti><c>get-flag</c></ti> > <ti>Trouve un paramètre, et retourne sa valeur.</ti> > </tr> > > <tr> > <ti><c>is-flag</c></ti> > <ti>Retourne vrai si le paramètre est déclaré dans les > variables actuelles <c>C[XX]FLAGS</c> ; ne fait que des > vérifications de paramètres complètes. > </ti> > </tr> > > <tr> > <ti><c>append-ldflags</c></ti> > <ti>Cette fonction ajoute des paramètres supplémentaires à la > variable <c>LDFLAGS</c>. > </ti> > </tr> > > <tr> > <ti><c>filter-ldflags</c></ti> > <ti>Enlève les paramètres spécifiés de <c>LDFLAGS</c>, et ne vérifie > les paramètres complets. > </ti> > </tr> > > <tr> > <ti><c>fstack-flags</c></ti> > <ti>Utilise -fno-stack-protector, ce qui supprime -fstack-protector et > -fstack-protector-all. > </ti> > </tr> > </table> > </body> > </subsection> > > > > <subsection> > <title>Règles à utiliser pour écrire un fichier ebuild</title> > <body> > <p> > Dans la mesure où les fichiers ebuilds ne sont effectivement que des > scripts shell, vous devriez pouvoir utiliser le mode d'écriture de > scripts shell de votre éditeur pour les éditer. Vous devez utiliser une > indentation correcte, en n'utilisant que des tabulations -- <e>pas > d'espaces</e>. Assurez-vous que votre éditeur affiche les tabulations > à moins de quatre espaces. Toujours s'assurer que vous utilisez des > crochets pour encadrer les variables d'environnement. Par exemple, <c> > ${P}</c> au lieu de simplement <c>$P</c>. > </p> > > <p> > Les longues lignes sont coupées avec des '\', comme par exemple : > </p> > > <pre caption="Couper une ligne dans un ebuild"> >./configure \ >--prefix=/usr || die "configure failed" > </pre> > > <p> > Pour plus de détails, référez-vous à <path>skel.ebuild</path> (en > général il se trouve dans <path>/usr/portage</path>). > </p> > > <p> > Si vous utilisez Vim pour éditer des ebuild/eclass, le fichier par > défaut de vimrc, <path>/etc/vim/vimrc</path>, s'assure déjà de la > correcte indentation, et des configurations concernant le type de > fichier des ebuild et eclass existe. Pour de meilleurs résultats, on > comme par exemple avoir une coloration syntaxique spécifique aux > mots-clefs des ebuilds, installez app-vim/gentoo-syntax. > </p> > > <p> > Sur les systèmes non Gentoo, vous pouvez obtenir des résultats > siminaires en utilisant les lignes suivantes dans votre vimrc, ou mieux > en installant les scripts <uri link= > "https://developer.berlios.de/projects/gentoo-syntax/">gentoo-syntax > </uri>. > </p> > > <pre caption="Configurer vimrc pour éditer des ebuilds"> >au BufRead,BufNewFile *.e{build,class} let is_bash=1|setfiletype sh >au BufRead,BufNewFile *.e{build,class} set ts=4 sw=4 noexpandtab > </pre> > > <p> > Si vous utilisez emacs, vous pouvez ajouter les lignes suivantes à la > fin de votre fichier .emacsrc (pour GNU Emacs) ou init.el (pour XEmacs) > pour vous assurer d'utiliser une configuration correcte lors de > l'édition de tout ce qui est lité à Gentoo : > </p> > > <pre caption="Configurer emacsrc pour éditer les ebuilds"> >(defun ebuild-mode () > (shell-script-mode) > (sh-set-shell "bash") > (make-local-variable 'tab-width) > (setq tab-width 4)) >(setq auto-mode-alist (cons '("\\.ebuild$" . ebuild-mode) auto-mode-alist)) >(setq auto-mode-alist (cons '("\\.eclass$" . ebuild-mode) auto-mode-alist)) > </pre> > > <p> > Si vous utilisez nano, alors vous avez de la chance ! Ãditez > simplement <path>/etc/nanorc</path> et décommentez la section liée aux > ebuilds. > </p> > </body> > </subsection> > > > > <subsection> > <title>Les variables USE</title> > <body> > <p> > l'objectif des variables USE est de vous permettre de configurer > Portage et de généraliser et automatiser l'utilisation ou la non > utilisation de certaines <e>options de compilation</e>. Voici un > exemple. Imaginons que vous soyez un fan de GNOME, et que vous voulez > que tous les ebuilds qui ont comme option de compilation (optionnel) > GNOME le supporte effectivement. Alors vous ajouteriez <c>gnome</c> à > votre variable <c>USE</c> dans <path>/etc/make.conf</path>, et alors > Portage ajoutera automatiquement les possibilités optionnelles de GNOME > dans vos ebuilds, si elles sont disponibles. Sinon, si vous ne voulez > pas des options GNOME dans vos ebuilds, alors qu'elles sont disponibles, > éditez tout simplement <path>/etc/make.conf</path> et assurez-vous que > <c>gnome</c> <e>n</e>'est <e>pas</e> présent dans la variable <c>USE > </c>. Gentoo a un nombre conséquent d'options USE, vous permettant > d'obtenir un système configuré exactement comme vous le souhaiteriez. > De plus vous pouvez désormais n'utiliser un paramètre <c>USE</c> que > pour certains paquets, en éditant le fichier <path> > /etc/portage/package.use</path>. > </p> > > <note> > Si vous enlevez un paramètre USE (par exemple, enlever <c>gnome</c> de > <c>USE</c>), cela ne fera que préciser à Portage de ne pas activer le > support <e>optionnel</e> de GNOME dans vos paquets. Cela dit, si vous > installez un ebuild qui <e>nécessite</e> GNOME, alors le paquet aura > evidemment le support de GNOME activé, comme vous pouviez vous en > douter. Cela signifie également que GNOME sera installé automatiquement > (en tant que dépendance) s'il ne l'était pas encore. C'est pourquoi > c'est toujours une bonne idée de faire un <c>emerge --pretend</c> (ou > mieux, un <c>emerge --ask</c>) avant de procéder à l'installation > effective. De cette manière, vous saurez exactement ce qui sera installé > par <c>emerge</c>. > </note> > > <p> > Dans vos propres ebuilds, vous pouvez vérifier si un paramètre USE est > présent ou non en utilisant la commande <c>use <variable></c>. > La commande <c>use</c> affiche <c><variable></c> si celle-ci est > présente dans les <c>USE</c> de l'utilisateur. Vous pouvez l'utiliser > comme suit : > </p> > > <pre caption="Vérifier qu'un paramètre USE est défini"> >if use X; then > # Commands specific to X... >fi > </pre> > > <p> > Les paramètres USE peuvent également être utilisés pour définir des > dépendances. Par exemple, vous voulez qu'un paquet soit nécessaire si > un paramètre USE précis est utilisé. Cela se fait en utilisant la > syntaxe <c>param? ( macategorie/monpaquet )</c> dans la variable <c> > DEPEND</c> de votre ebuild. Dans cet exemple, <c>macategorie/monpaquet > </c> ne seront requis qus si <c>param</c> est présent dans <c>USE</c>. > Il est également possible de spécifier une dépendance qui devrait être > honorée si un certain paramètre USE <e>est</e> présent, et quelle > dépendance devrait être utilisée si il <e>n</e>'est <e>pas</e> présent. > Cela se fait ainsi : <c>param? ( macat/monpaquet)</c> et > <c>!param? ( autrecat/autrepaquet )</c>. Dans ce cas, si <c>param</c> > n'est pas présent, <c>autrecat/autrepaquet</c> sera utilisé à la place > de <c>macat/monpaquet</c>. Assurez-vous que vos ebuilds utilisent cette > syntaxe et non pas une boucle conditionnelle BASH. Les conditions BASH > interfèrent avec le cache des dépendances de Portage, et l'utilisation > de celles-ci casserait votre ebuild. > </p> > > <p> > Voici un petit truc important sur comment utiliser <c>USE</c>. La > plupart du temps, un paquet aura un script <c>./configure</c> utilisé > pour effectuer les diverses étapes de configuration. En général, si > votre ebuild utilise <c>./configure</c>, toutes les fonctionnalités > optionnelles seront activées ou désactivées en passant les bons > arguments à la commande <c>./configure</c>. Voici le meilleur moyen de > se débarrasser de ce problème : > </p> > > <pre caption="Conditions utilisant les paramètres USE"> >DEPEND="X? ( >=x11-base/xfree-4.3 ) >mysql? ( >=dev-db/mysql-3.23.49 ) >apache2? ( >=net-www/apache-2 ) >!apache2? ( =net-www/apache-1* )" > >src_compile() { > econf \ > `use_enable X x11` \ > `use_enable mysql` \ > || die "Error: econf failed!" > emake || die "Error: emake failed!" >} > </pre> > > <p> > Cette méthode produit un très bon résultat. Nous n'avons pas à nous > préoccuper de savoir quels sont les configurations par défaut pour mysql > ou X (activé/désactivé), nous disons explicitement à <c>econf</c> ce que > nous voulons qu'il fasse, d'après ce que l'on a dans les paramètres <c> > USE</c>. En plus, ça produit un code propre et facile à lire :). > </p> > > <p> > Pour avoir une table mise à jour en permanence des paramètres USE, voyez > <uri link="http://www.gentoo.org/dyn/use-index.xml">ce lien</uri>. > </p> > </body> > </subsection> ></section> > > > > > ><section> ><title>Emplacements des systemes de fichiers</title> > <subsection> > <title>Introduction à FHS</title> > <body> > <p> > Les standards de couche de systèmes de fichiers utilisés dans Gentoo > Linux suivent de près le système FHS (pour <e>File system Hierarchy > Standard</e>, standard de hiérarchie dans les systèmes de fichiers). Une > description simplifiée de ce standard vous est proposée ici ; pour > avoir les spécifications complètes, vous pouvez consulter > <uri>http://www.pathname.com/fhs/</uri>. > </p> > > <note> > La hiérarchie <path>/opt</path> est donnée dans la section 3.12 du FHS. > La section 4.4 s'occupe de ce qui concerne le répertoire <path> > /usr/X11R6</path>. KDE et GNOME ne sont pas précisés dans le standard, > et ne sont en fait même pas mentionnés dans la version actuelle de FHS. > </note> > </body> > </subsection> > > > > <subsection> > <title>Comment placer vos paquets dans le système de fichiers</title> > <body> > <p> > Normalement, si le paquet utilise autoconf et automake, les destinations > par défaut de l'installation du paquet sont en général correctes, à > quelques exceptions près : > </p> > > <ul> > <li> > Si vous installez un programme dans <path>/bin</path>, <path>/sbin > </path>, <path>/usr/bin</path>, ou <path>/usr/sbin</path>, alors les > pages de manuel correspondant à votre programme devraient être > installées dans le répertoire <path>/usr/share/man</path>. Cela peut > se faire en général en le spécifiant dans l'ebuild avec <c> > ./configure --mandir=/usr/share/man</c>. > </li> > <li> > Les fichiers info GNU doivent toujours être installés dans <path> > /usr/share/info</path>, <e>même si les fichiers info sont à propos de > programmes et outils spécifiques à X11, GNOME ou KDE. Prenez-en note. > <path>/usr/share/info</path> et l'<e>unique</e> emplacement officiel > pour les fichiers info GNU. Dans la mesure ou plusieurs scripts > <c>./configure</c> installent pas défaut les fichiers info GNU dans > <c>/usr/info</c>, il est souvent nécessaire de faire un appel à <c> > ./configure</c> avec pour argument <c>--infodir=/usr/share/info</c>. > </li> > <li> > Les fichiers de documentation sont installés dans <path> > /usr/share/doc</path>, dans un sous-répertoire reflétant le nom, la > version et la révision d'un programme particulier. Cela s'applique à > tous les programmes : GNOME, KDE, X11 etc. Cependant, certains > programmes installerons de la documentation supplémentaire les > supportera ces fichiers dans la hiérarchie <path>/usr/share</path> > pour leurs propres besoins. > </li> > <li> > Les programmes et bibliothèques spécifiques à X11 doivent toujours > être installés dans <path>/usr</path> et non directement dans <path> > /usr/X11R6</path>. Nous réservons la hiérarchie <path>/usr/X11R6 > </path> pour le système de fenêtre X, version 11, sortie R6 <e> > en personne</e>. D'autres distributions auront probablement fait une > interprétation différente du FHS concernant cette hiérarchie. > </li> > <li> > Les programmes GNOME et KDE, de la même manière, doivent être > installés dans <path>/usr</path>. > </li> > </ul> > > <impo> > Certaines distributions choisissent d'installer GNOME et KDE dans > <path>/opt</path>. Il n'existe aucun standard pour ces environnements > de bureau concernant l'endroit où doivent être installés leurs > fichiers. Dans une optique de simplicité et de consistance, nous avons > choisi d'installer tous les paquets KDE et GNOME dans la hiérarchie > <path>/usr</path>. > </impo> > > <p> > En général, vos ebuilds doivent installer leurs fichiers dans > l'arborescence <path>/usr</path>. <e>Quelques</e> programmes peuvent > être compilés et liés avec ou non des bibliothèques de GNOME, KDE, X11, > ce qui peut causer un peu de confusion. Notre solution consiste à tout > installer dans <path>/usr</path>, ce qui empêche les ambiguités et > évitent une complexité non nécessaire pour les auteurs d'ebuilds. > L'emplacement dans lequel doivent être installés les fichiers d'un > programme <e>ne</e> doit <e>pas</e> dépendre de la présence ou absence > de paramètres <c>USE</c>. Du coup, les ebulids dans l'arbre de Portage > s'installent <e>presque toujours</e> dans la hiérarchie <path>/usr > </path> exclusivement. > </p> > > <note> > Le répertoire <path>/opt</path> est réservé dans Gentoo aux paquets > uniquement binaires. Par exemple, mozilla-bin, acroread, netscape et > realplayer. Les paquets installés ici auront en général un fichier > d'ébauche <path>/etc/env.d/foo</path>. Cela a pour objectif d'inclure > dans l'environnement les répertoires et les variables additionnelles > nécessaires. Pour plus d'informations sur <path>/etc/env.d</path>, > lisez <uri link= > "/doc/en/handbook/handbook-x86.xml?part=2&chap=5">ce document > </uri>. > </note> > </body> > </subsection> ></section> > > > > ><section> ><title>Les scripts et utilitaires de Portage</title> > <subsection> > <title>Scripts publiques</title> > <body> > <p> > Il existe des scripts utilisés par l'administrateur système pour > installer ou supprimer les paquets, et pour maintenir à jour la base > de données des paquets. > </p> > > <p> > <c>ebuild</c> est l'outil de base du système de Portage : il > effectue toutes les taches principales comme par exemple désarchiver, > compiler, installer, fusionner, désinstaller les paquets. Il est appelé > en utilisant la commande : <c>ebuild dir/vers/paquet.ebuild > commande</c>. Les commandes disponibles sont : > </p> > > <table> > <tr> > <th>Commande</th> > <th>Description</th> > <th>Fonction <c>ebuild</c> associée</th> > </tr> > > <tr> > <ti><c>setup</c>*</ti> > <ti>Effectue toutes les commandes nécessaires avant qu'un ebuild > ne commence son travail > </ti> > <ti><c>pkg_setup</c></ti> > </tr> > > <tr> > <ti><c>depend</c></ti> > <ti>Affiche les dépendances requises à la construction du paquet.</ti> > <ti>N/A</ti> > </tr> > > <tr> > <ti><c>merge</c>*</ti> > <ti>Désarchive, compile, installe et fusionne le paquet dans le > système de fichiers. > </ti> > <ti>N/A</ti> > </tr> > > <tr> > <ti><c>qmerge</c>*</ti> > <ti>Fusionne le paquet dans le système de fichiers, en supposant que > le désarchivage, la compilation et l'installation ont déjà été > exécutés. > </ti> > <ti>N/A</ti> > </tr> > > <tr> > <ti><c>unpack</c>*</ti> > <ti>Désarchive une archive source dans le répertoire de travail.</ti> > <ti><c>src_unpack</c></ti> > </tr> > > <tr> > <ti><c>compile</c>*</ti> > <ti>Compile le paquet.</ti> > <ti><c>src_compile</c></ti> > </tr> > > <tr> > <ti><c>rpm</c></ti> > <ti>Crèe un RPM à partir du paquet.</ti> > <ti>N/A</ti> > </tr> > > <tr> > <ti><c>package</c></ti> > <ti>Crèe un paquet Gentoo <c>tbz2</c>.</ti> > <ti>N/A</ti> > </tr> > > <tr> > <ti><c>prerm</c>*</ti> > <ti>Exécute une étape de pré-suppression de paquet.</ti> > <ti><c>pkg_prerm</c></ti> > </tr> > > <tr> > <ti><c>postrm</c>*</ti> > <ti>Exécute une étape de port-suppression de paquet.</ti> > <ti><c>pkg_postrm</c></ti> > </tr> > > <tr> > <ti><c>preinst</c>*</ti> > <ti>Exécute une étape de pré-installation du paquet.</ti> > <ti><c>pkg_preinst</c></ti> > </tr> > > <tr> > <ti><c>postinst</c>*</ti> > <ti>Execute une étape de post-installation du paquet.</ti> > <ti><c>pkg_postinst</c></ti> > </tr> > > <tr> > <ti><c>config</c></ti> > <ti>Met en place une configuration par défaut, une fois que le paquet > a été fusionné. > </ti> > <ti><c>pkg_config</c></ti> > </tr> > > <tr> > <ti><c>touch</c>*</ti> > <ti>Met à jour le mtimes pour chaque archive source dans un paquet. > </ti> > <ti>N/A</ti> > </tr> > > <tr> > <ti><c>clean</c>*</ti> > <ti>Nettoie le répertoire de travail pour un paquet.</ti> > <ti>N/A</ti> > </tr> > > <tr> > <ti><c>fetch</c>*</ti> > <ti>Récupère les archives source du paquet.</ti> > <ti>N/A</ti> > </tr> > > <tr> > <ti><c>digest</c>*</ti> > <ti>Crpee un fichier digest pour un paquet.</ti> > <ti>N/A</ti> > </tr> > > <tr> > <ti><c>install</c>*</ti> > <ti>Installe le paquet dans le répertoire image.</ti> > <ti><c>src_install</c></ti> > </tr> > > <tr> > <ti><c>unmerge</c></ti> > <ti>Désinstalle le paquet du système de fichiers.</ti> > <ti>N/A</ti> > </tr> > </table> > > <note> > Les commandes avec une astérisque (*) ne sont en généralement utilisées > que pas le développeur. > </note> > > <p> > <c>emerge</c> installe de manière récursive le paquet et toutes ses > dépendances dans le système de fichiers. Cette commande a de nombreuses > options, faites un <c>emerge --help</c> pour en avoir la liste. > </p> > > <p> > <c>env-update</c> met à jour les fichiers de configuration (entre > autres, mais pas seulement, <path>/etc/ld.so.conf</path> et <path> > /etc/profile.env</path>) pour inclure les changements effectués par les > paquets installés. > </p> > </body> > </subsection> > > > > <subsection> > <title>Scripts et commandes privés</title> > <body> > <p> > Il existe des scripts que vous pouvez utiliser dans vos fichiers ebuilds > pour réaliser des taches communes. > </p> > > <p> > Si vous voulez un aperçu, jetez un oeil aux scripts en eux-même dans > <path>/usr/lib/portage/bin</path>. > </p> > > <table> > <tr> > <th>Commande</th> > <th>Valeur par défaut</th> > <th>Description</th> > <th>Exemple</th> > </tr> > > <tr> > <ti><c>diropts</c></ti> > <ti>-m0755</ti> > <ti>Fixe les options utilisées lors de l'utilisation de <c>dodir</c>. > </ti> > <ti><c>diropts -m0750</c></ti> > </tr> > > <tr> > <ti><c>dobin</c></ti> > <ti>N/A</ti> > <ti>Installe les binaires spécifiés dans <path>DESTTREE/bin</path>. > </ti> > <ti><c>dobin wmacpi</c></ti> > </tr> > > <tr> > <ti><c>docinto</c></ti> > <ti><path>""</path></ti> > <ti>Fixe le sous-répertoire relatif utilisé par <c>dodoc</c> (<e> > DOCDESTREE</e>) > </ti> > <ti><c>docinto exemples</c></ti> > </tr> > > <tr> > <ti><c>dodir</c></ti> > <ti>N/A</ti> > <ti>Crèe un répertoire, en utilisant de manière transparente ${D}. > </ti> > <ti><c>dodir /usr/lib/nouveaupaquet</c></ti> > </tr> > > <tr> > <ti><c>dodoc</c></ti> > <ti>N/A</ti> > <ti>Installe les fichiers spécifiés dans le répertoire de > documentation du paquet en question (<path> > /usr/share/doc/${PF}/DOCDESTTREE</path>) (voir <c>docinto</c>). > </ti> > <ti><c>dodoc README *.txt</c></ti> > </tr> > > <tr> > <ti><c>doexe</c></ti> > <ti>N/A</ti> > <ti>Installe les fichiers spécifiés avec le mode <e>EXEOPTIONS</e> > (voir <c>exeopts</c>) dans <path>EXEDESTTREE</path> (voir > <c>exeinto</c>). > </ti> > <ti><c>doexe ${FILESDIR}/quake3</c></ti> > </tr> > > <tr> > <ti><c>dohard</c></ti> > <ti>N/A</ti> > <ti>Crèe un lien dur, en utilisant de manière transparente ${D}.</ti> > <ti><c>dohard ls /bin/dir</c></ti> > </tr> > > <tr> > <ti><c>dohtml</c></ti> > <ti>N/A</ti> > <ti>Installe les fichiers spécifiés et les répertoires dans <path> > /usr/share/doc/${PF}/html</path>. > </ti> > <ti><c>dohtml -r doc/html/*</c></ti> > </tr> > > <tr> > <ti><c>doinfo</c></ti> > <ti>N/A</ti> > <ti>Installe les fichiers spécifiés dans <path>/usr/share/info</path>, > puis les compresse avec gzip. > </ti> > <ti><c>doinfo doc/*.info</c></ti> > </tr> > > <tr> > <ti><c>doins</c></ti> > <ti>N/A</ti> > <ti>Installe les fichiers spécifiés avec le mode <c>INSOPTIONS</c> > (voir <c>insopts</c>) dans <path>INSDESTTREE</path> (voir > <c>insinto</c>). > </ti> > <ti><c>doins *.png icone.xpm</c></ti> > </tr> > > <tr> > <ti><c>dolib</c></ti> > <ti>N/A</ti> > <ti>Installe les bilbiothèques spécifiées dans <path>DESTTREE/lib > </path> avec le mode 0644. > </ti> > <ti><c>dolib *.a *.so</c></ti> > </tr> > > <tr> > <ti><c>dolib.a</c></ti> > <ti>N/A</ti> > <ti>Installe les bibliothèques spécifées dans <path>DESTTREE/lib > </path> avec le mode 0644. > </ti> > <ti><c>dolib.a *.a</c></ti> > </tr> > > <tr> > <ti><c>dolib.so</c></ti> > <ti>N/A</ti> > <ti>Installe les bibliothèques spécifées dans <path>DESTTREE/lib > </path> avec le mode 0755. > </ti> > <ti><c>dolib.so *.so</c></ti> > </tr> > > <tr> > <ti><c>doman</c></ti> > <ti>N/A</ti> > <ti>Installe les fichiers spécifiés dans <path>/usr/share/man/manX > </path>, selont le suffixe su fichier (file.1 ira dans <path> > man1</path>). > </ti> > <ti><c>doman *.1 *.5</c></ti> > </tr> > > <tr> > <ti><c>dosbin</c></ti> > <ti>N/A</ti> > <ti>Installe les fichiers dans <path>DESTTREE/sbin</path>, en > s'assurant qu'ils sont exécutables. > </ti> > <ti><c>dosbin ksymoops</c></ti> > </tr> > > <tr> > <ti><c>dosym</c></ti> > <ti>N/A</ti> > <ti>Crèe un lien symbolique, en utilisant ${D} de manière > transparente. > </ti> > <ti><c>dosym gzip /bin/zcat</c></ti> > </tr> > > <tr> > <ti><c>emake</c></ti> > <ti>N/A</ti> > <ti>Lance make avec <c>MAKEOPTS</c>. Certains paquets ne peuvent pas > être faits en parallèle. Utilisez <c>emake -j1</c> pour y > échapper. Si vous devez passer des arguments supplémentaires à > make, donnez-les simplement à la commande emage. Les utilisateurs > peuvent utiliser la variable d'environnement <c>EXTRA_EMAKE</c> > pour passer des paramètres supplémentaires à emake. > </ti> > <ti><c>emake</c></ti> > </tr> > > <tr> > <ti><c>exeinto</c></ti> > <ti><path>/</path></ti> > <ti>Fixe la racine (<e>EXEDESTTREE</e>) pour la commande <c>doexe > </c>. > </ti> > <ti><c>exeinto /usr/lib/${PN}</c></ti> > </tr> > > <tr> > <ti><c>exeopts</c></ti> > <ti>-m0755</ti> > <ti>Fixe les options utilisées lors de l'utilisation de <c>doexe</c>. > </ti> > <ti><c>exeopts -m1770</c></ti> > </tr> > > <tr> > <ti><c>fowners</c></ti> > <ti>N/A</ti> > <ti>Applique l'appartenance spécifique d'un fichier à un utilisateur, > en utilisant la commande chown, et en utilisant ${D} de manière > transparente. > </ti> > <ti><c>fowners root:root /sbin/fonctions.sh</c></ti> > </tr> > > <tr> > <ti><c>fperms</c></ti> > <ti>N/A</ti> > <ti>Appliques les permissions spécifiques à un fichier spécifique via > la commande chmod, en utilisant ${D} de manière transparente. > </ti> > <ti><c>fperms 700 /var/consoles</c></ti> > </tr> > > <tr> > <ti><c>insinto</c></ti> > <ti><path>/usr</path></ti> > <ti>Fixe la racine (<e>INSDESTTREE</e>) pour la commande <c>doins</c>. > </ti> > <ti><c>insinto /usr/include</c></ti> > </tr> > > <tr> > <ti><c>insopts</c></ti> > <ti>-m0644</ti> > <ti>Fixe les options utilisées lors du lancement de <c>doins</c>.</ti> > <ti><c>insopts -m0444</c></ti> > </tr> > > <tr> > <ti><c>into</c></ti> > <ti><path>/usr</path></ti> > <ti>Fixe le préfixe de la cible (<path>DESTTREE</path>) pour toutes > les commandes 'do' (comme <c>dobin</c>, <c>dolib</c>, <c>dolib.a > </c>, <c>dolib.so</c>, <c>domo</c>, <c>dosbin</c>). > </ti> > <ti><c>into /</c></ti> > </tr> > > <tr> > <ti><c>libopts</c></ti> > <ti>-m0644</ti> > <ti>Fixe les options utilisées lors de l'exécution de <c>dolib</c>. > </ti> > <ti><c>libopts -m0555</c></ti> > </tr> > > <tr> > <ti><c>newbin</c></ti> > <ti>N/A</ti> > <ti>Couche supplémentaire à <c>dobin</c> qui installe le binaire > spécifique et le renomme de manière transparente au second > argument. > </ti> > <ti><c>newbin ${FILESDIR}/vmware.sh vmware</c></ti> > </tr> > > <tr> > <ti><c>newdoc</c></ti> > <ti>N/A</ti> > <ti>Surcouche de <c>dodoc</c> qui installe le fichier spécifié et le > renomme de manière transparente au second argument. > </ti> > <ti><c>newdoc README README.opengl</c></ti> > </tr> > > <tr> > <ti><c>newexe</c></ti> > <ti>N/A</ti> > <ti>Surcouche de <c>doexe</c> qui installe le fichier spécifié et le > renomme de manière transparente au second argument. > </ti> > <ti><c>newexe ${FILESDIR}/xinetd.rc xinetd</c></ti> > </tr> > > <tr> > <ti><c>newins</c></ti> > <ti>N/A</ti> > <ti>Surcouche de <c>doins</c> qui installe le fichier spécifié et le > renomme de manière transparente au second argument. > </ti> > <ti><c>newins ntp.conf.example ntp.conf</c></ti> > </tr> > > <tr> > <ti><c>newman</c></ti> > <ti>N/A</ti> > <ti>Surcouche de <c>doman</c> qui installe le fichier spécifié et le > renomme de manière transparente au second argument. > </ti> > <ti><c>newman xboing.man xboing.6</c></ti> > </tr> > > <tr> > <ti><c>newsbin</c></ti> > <ti>N/A</ti> > <ti>Surcouche de <c>dosbin</c> qui installe le fichier spécifié et le > renomme de manière transparente au second argument. > </ti> > <ti><c>newsbin strings strings-static</c></ti> > </tr> > > <tr> > <ti><c>prepall</c></ti> > <ti>N/A</ti> > <ti>Lance <c>prepallman</c>, <c>prepallinfo</c> et <c>prepallstrip > </c>. S'assure de plus que toutes les bibliothèques dans <path> > /opt/*/lib</path>, <path>/lib</path>, <path>/usr/lib</path> et > <path>/usr/X11R6/lib</path> sont exécutables. Enfin, déplace et > isole les macros aclocal dans <path>/usr/share/aclocal</path>. > </ti> > <ti><c>prepall</c></ti> > </tr> > > <tr> > <ti><c>prepalldocs</c></ti> > <ti>N/A</ti> > <ti>gzippe de manière récursice tous les fichiers de documentation > dans <path>/usr/share/doc</path>, en tenant compte de manière > transparente des directions de liens symboliques. > </ti> > <ti><c>prepalldocs</c></ti> > </tr> > > <tr> > <ti><c>prepallinfo</c></ti> > <ti>N/A</ti> > <ti>gxippe récursivement tous les fichiers info dans <path> > /usr/share/info</path> > </ti> > <ti><c>prepallinfo</c></ti> > </tr> > > <tr> > <ti><c>prepallman</c></ti> > <ti>N/A</ti> > <ti>gzippe récursivement toutes les pages man (de manuel) dans <path> > /opt/*/man/*</path>, <path>/usr/share/man/*</path>, <path> > /usr/local/man/*</path>, <path>/usr/X11R6/share/man/*</path> et > s'occupe de manière transparente de toutes les directions de > liens symboliques. > </ti> > <ti><c>prepallman</c></ti> > </tr> > </table> > </body> > </subsection> ></section> > > > > ><section> ><title>Les dépendances de paquet</title> > <subsection> > <title>Pourquoi les dépendances sont importantes ?</title> > <body> > <p> > Portage est plus qu'un simple script qui vous permet d'unifier la > méthode d'installation d'un projet quelconque (programme, bibliothèque) > à partir des sources. Il récupère et installe également toutes les > dépendances nécessaires si vous les spécifiez correctement dans votre > ebuild. > </p> > > <p> > Dans les ebuilds officiels, toutes les dépendances ont été spécifiées, > de telle manière que si vous faites un <c> > emerge net-www/mozilla/mozilla-1.0</c>, Portage s'assurera que toutes > les bibliothèques nécessaires à Mozilla seront construites et installées > correctement avant que Mozilla ne soit lui-même construit. > </p> > > <p> > Portage va même jusqu'à distinquer les dépendances dûes à la compilation > et celles dûes au lancement. Cela dit, pour le moment, Portage installe > toutes les dépendances de compilation et de lancement, et laisse l'état > tel quel. Dans une prochaine version, il est prévu de rentre possible > de faire en sorte que seules les dépendances de lancement soient > effectivement installées. > </p> > </body> > </subsection> > > > > <subsection> > <title>Comment préciser les dépendances à vos fichiers ebuild ?</title> > <body> > <p> > La variable <c>DEPEND</c> dans votre <path>foo-x.y.z.ebuild</path> > indique à Portage les paquets qui sont nécessaires à la construction > de <path>foo</path>. La variable <c>RDEPEND</c> indique à Portage les > paquets nécessaires à son lancement. > </p> > > <pre caption="Exemple de dépendances"> >DEPEND="virtual/glibc > sys-libs/zlib" >RDEPEND="virtual/glibc" > </pre> > > <p> > Cela indique à Portage de construire <path>foo-x.y.z</path>, les paquets > <path>virtual/glibc</path> (plus de précisions sur les virtuals seront > données plus loin) et <path>sys-libs/zlib</path> étant nécessaires à > la construction. Il ne précise pas la version de glibc ou zlib dont > vous avez besoin, ce qui signifie que "n'importe laquelle" ira très > bien. > </p> > > <p> > La mention de "n'importe laquelle" fait évidemment un peu peur, et ne > fonctionnera en général pas. En revanche pour des bibliothèques > centrales comme glibc, qui fait tout pour avoir des binaires toujours > compatibles, dans ce cas-là , ça fonctionnera. Pour d'autres > bibliothèques, on peut évidemment préciser la version des dépendances. > </p> > > <pre caption="Exemple avec les versions"> >>=sys-apps/bar-1.2 >=sys-apps/baz-1.0 > </pre> > > <p> > >= et = font bien ce qu'on pense qu'ils feront : Toutes les > versions plus récentes que sys-apps/bar version 1.2 iront (ce qui > signifie aussi que sys-apps/bar-2.0 suffira), alors que sys-apps/baz > version 1.0 est l'unique version acceptée. Pour plus d'informations sur > le schémar de version des paquets voir la section plus haut sur comment > <uri link="#doc_chap2_sect2">nommer des fichiers ebuild</uri>. > </p> > > <p> > Voici d'autres méthodes pour spécifier la version des dépendances : > </p> > > <pre caption="Spécifier la version des dépendances"> >~sys-apps/qux-1.0 >=sys-apps/foo-1.2* >!sys-libs/gdbm > </pre> > > <p> > ~sys-apps/qux-1.0 va sélectionner la plus récente révicion de qux-1.0 > dans Portage. > </p> > > <p> > =sys-apps/foo-1.2* va selectionner le membre le plus récent de la série > 1.2, mais ignorera la 1.3 et les versions plus récentes/vieilles. Ainsi, > foo-1.2.3 et foo-1.2.0 sont tous les deux valides, mais foo-1.3.3, > foo-1.3.0, et foo-1.1.0 ne le sont pas. > </p> > > <p> > !sys-libs/gdbm vous empêchera d'installer ce paquet tant que gdbm est > déjà installé. > </p> > > <note> > Pour les derniers détails sur les éléments DEPEND, lisez la section 5 de > la page de manuel sur les ebuilds : <c>man 5 ebuild</c>. > </note> > </body> > </subsection> ></section> > > > > ><section> ><title>Tester et déployer</title> > <subsection> > <title>ChangeLog</title> > <body> > <p> > Dès que vous mettez à jour un (ou que vous écrivez un nouveau) ebuild, > vous devez également mettre à jour (ou créer) le ChangeLog > correspondant. Le fichier <path>skel.ChangeLog</path> contient un > exemple de ChangeLog que vous pouvez utiliser comme base. > </p> > > <p> > L'objectif du ChangeLog est de documenter <e>ce qui a été fait</e>, > <e>pourquoi</e> cela a été fait, et <e>par qui</e>. Cela permet à la > fois aus développeurs et aux utilisateurs de garder une trace des > changements effectués, de manière simple. > </p> > > <p> > Le ChangeLog est tout d'abord fait pour les utilisateurs, donc > assurez-vous qu'il reste court (jusqu'à un certain point), et évitez > de devenir verbeux sur les détails techniques internes. > </p> > </body> > </subsection> > > > > <subsection> > <title>Sauver vos propres ebuilds localement</title> > <body> > <p> > Afin de pouvoir tester vos ebuilds et de les laisser à la connaissance > de Portage, vous devez les placer dans un répertoire connu. Portage > utilisera la variable <c>PORTDIR_OVERLAY</c> que vous pouvez définir > dans <path>/etc/make.conf</path>. Vous devriez fixer cette variable à > votre répertoire (par exemple, <path>/usr/local/portage</path>). > </p> > > <p> > Dans ce répertoire vous devez avoir la même structure (et les mêmes > catégories) que dans <path>/usr/portage</path>. > </p> > > <p> > En utilisant <c>PORTDIR_OVERLAY</c>, vos ebuilds restent sur votre > sustème, même après un <c>emerge sync</c>, et ils restent connus de > Portage. > </p> > </body> > </subsection> > > > > <subsection> > <title>Outils de tests utiles</title> > <body> > <p> > On dispose de quelques outils pratiques pour vous aider à écrire et > maintenir vos ebuilds. > </p> > > <warn> > <c>lintool</c> est cassé. Utilisez repoman à la place. > </warn> > > <table> > <tr> > <th>Outil</th> > <th>Paquet</th> > <th>Description</th> > </tr> > > <tr> > <ti><c>repoman</c></ti> > <ti>sys-apps/portage</ti> > <ti>Un outil pour les développeurs uniquement, pour les assister dans > la procédure de vérification pour déposer un ebuild dans le CVS. > Il effectue de nombreuses vérifications communes de qualité (QA) > et essaye de s'assurer que les fichiers ajoutés dans le cvs ne > vont pas casser l'arborescence de Portage. > </ti> > </tr> > > <tr> > <ti><c>ccache</c></ti> > <ti>dev-util/ccache</ti> > <ti>Outil qui garde les fichiers en pré-processus, pour pouvoir rendre > la compilation <e>plus</e> rapide. Assurez-vous d'ajouter <c> > ccache</c> dans votre variable <c>FEATURES</c> dans <path> > /etc/make.conf</path> ! > </ti> > </tr> > > <tr> > <ti><c>sandboxshell</c></ti> > <ti>app-shells/sandboxshell</ti> > <ti>Lance un shell qui crèe un environnement "bac à sable". Très > utile pour entrer dans le même environnement que celui dans lequel > Portage construit les paquets, et y débugger à la main. > </ti> > </tr> > > <tr> > <ti><c>echangelog</c></ti> > <ti>app-portage/gentoolkit-dev</ti> > <ti>Permet de créer un nouveau ChangeLog ou d'ajouter une entrée dans > un ChangeLog déjà existant. > </ti> > </tr> > > <!-- > <tr> > <ti><c>gentool-bump-revision</c></ti> > <ti>app-portage/gentoolkit</ti> > <ti>Outil pour les développeurs uniquement, qui effectue un "bump" > du numéro de révision, ajoute une nouvelle révision au CVS, enlève > l'ancienne, et met à jour le ChangeLog de manière cohérente. > </ti> > </tr> > --> > > <tr> > <ti><c>qpkg</c></ti> > <ti>app-portage/gentoolkit</ti> > <ti>Un outil qui propose plusieurs informations à propos des paquets > installés. > </ti> > </tr> > </table> > </body> > </subsection> ></section> ></sections>
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Raw
Actions:
View
Attachments on
bug 73654
:
45425
|
45432
|
45439
|
45441
|
45453
|
45595
|
45596
|
45893
|
45894
|
45895
|
45897
|
45961
|
47829
|
47830
|
47831
|
54040
|
54041
|
54042
|
54043
|
55255
|
55256
|
55257
|
55258
|
55259
|
55261
|
55487
|
55958
|
56147
|
56557