Go to:
Gentoo Home
Documentation
Forums
Lists
Bugs
Planet
Store
Wiki
Get Gentoo!
Gentoo's Bugzilla – Attachment 55255 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]
devrel-gentoo-howto.xml
devrel-gentoo-howto.xml (text/plain), 71.07 KB, created by
Clément VARALDI
on 2005-04-04 02:30:21 UTC
(
hide
)
Description:
devrel-gentoo-howto.xml
Filename:
MIME Type:
Creator:
Clément VARALDI
Created:
2005-04-04 02:30:21 UTC
Size:
71.07 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 --> > ><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 se trouve 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 spécifié 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 déjà >ebuild pour ce que vous voulez faire, mais qui n'aurait 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 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 et d'espace disque inutiles 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 >correctement les développeurs de la présence de conflits. ></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 disposez d'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> >Vérifiez de nouveau votre ebuild pour vous assurer de sa bonne correction 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 exécuter la >commande <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 exécuter <c>repoman scan</c> avant de soumettre son travail ; > </li> > <li>Exécutez <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 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 de destination 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 >les 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 identifiables entre eux, >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 >l'usage habituel, car c'est plus commode. ></p> ></body> ></subsection> ></section> > > > > ><section> ><title>Scripts ebuild</title> ><subsection> ><title>Introduction</title> ><body> ><p> >Les scripts ebuild sont la base de l'ensemble du système de Portage. Ils >contiennent toutes les informations nécessaires pour récupérer, désarchiver, >compiler et installer un ensemble de sources. Ils contiennent aussi les >informations nécessaires pour réaliser n'importe quelle tâche de pré/post >installation/suppression ou de configuration. Si la plus grande 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 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 par rapport à <c>ebuild</c>. Il a la capacité d'installer >automatiquement les dépendances si elles sont nécessaires et 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'erreurs précieux, car il vous permettra d'isoler les >problèmes d'un ebuild par parties spécifiques. ></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 >« - », blanc souligné « _ », 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>, <c>bar-2.4.6</c>, etc. ></p> > ><impo> >Si vous pensez utiliser une lettre à la fin de la version du paquet, n'oubliez >pas que ce caractère <e>ne doit pas</e> être utilisé pour signifier le statut ><em>alpha</em> ou <em>beta</em> d'un paquet, dans la mesure ou les ><em>alpha</em> et <em>beta</em> 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 paquet <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éliorations 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évision augmenté 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'oubliez <e>jamais</e> de laisser une mention de vos >modifications dans le fichier <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ème 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 variables que 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ù sont mis tous > les fichiers récupérés pour un paquet. 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é lors de > l'exécution de l'ebuild à la manière du répertoire <path>/tmp</path> mais > est virtuel. > </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 > une racine d'arborescence (<path>/</path>) virtuelle. > </ti> ></tr> > ><tr> > <ti><c>SLOT</c></ti> > <ti>MUST</ti> > <ti> > Portage manipule souvent plusieurs versions d'un même programme installées. > Par exemple vous pouvez avoir 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 la > valeur <c>2</c> alors que nous aurions utilisé la valeur <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 la licence du programme, par exemple GPL-2, BSD, > etc. Ce champ doit être initialisé à une valeur de licence valide (qui peut > être n'importe quelle licence présente 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 d'ajouter l'ebuild à 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 rôles. Tout d'abord, > elle spécifie la cible 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 pas à jour, 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 profil 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 liens pour chaque fichier source de votre paquet, en les séparant d'u > 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 paquets similaires. > </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 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 tâche qui soit > un 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 manuelles nécessaires si pour une raison > ou pour une autre (comme par exemple des conditions liées à la licence) les > sources ne seraient pas récupérables 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 et 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éfinit 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 utilisant <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> > Cette fonction n'est exécuté que si vous avez fait initialisé la variable > <c>FEATURES="maketest"</c> et si <c>RESTRICT="maketest"</c> n'est pas mis. > La fonction par défaut exécutera une fonction de test disponible dans > n'importe quel fichier 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 foobar</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 couple > <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éfinit, 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 > paramètres <c>USE</c>. > </ti> ></tr> > ><tr> > <ti><c>use_enable</c></ti> > <ti> > Même fonction 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 connaît la version du noyau. Si non, cette fonction > retourne une erreur et se termine immédiatement. Si vous avez besoin d'un > 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 un 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>, créer un tel fichier soi-même pourrait casser le paquet. > </ti> ></tr> > ><tr> > <ti><c>econf</c></ti> > <ti> > Exécute <c>./configure</c> avec les changements de répertoires nécessaires > (prefix, host, mandir, infodir, datadir, sysconfdir, localstatedir). Vous > pouvez lui passer de manière optionnelle 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 à econf. En d'autres > termes, le premier argument passé sera toujours remplacé par le dernier. > </ti> ></tr> > ><tr> > <ti><c>einstall</c></ti> > <ti> > Exécute <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 méthode 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 en fait 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 passés en arguments à <c>die</c> si vous faites > plusieurs appels à <c>die</c> dans une même fonction par exemple. Si vous > n'en utilisez pas, il sera plus dur de rechercher une erreur car vous ne > pourrez pas être 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 donné à 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 dans votre ebuild pour pouvoir 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 processeurs présents et ajoute dans > <c>MAKEOPTS</c> l'option correcte -jX correspondante. > </ti> ></tr> > ><tr> > <ti><c>mymktemp</c></ti> > <ti> > Cette fonction effectuera un appel à mktemp si elle existe, ou agira comme > un remplacement à mktemp quand elle n'existe pas. > </ti> ></tr> > ><tr> > <ti><c>edos2unix</c></ti> > <ti> > Cette fonction effectue la même tâche que le binaire <c>dos2unix</c>. > </ti> ></tr> > ><tr> > <ti><c>egetent</c></ti> > <ti> > egetent est une abstraction de <c>getent</c> sous Linux, ou <c>nidump</c> > sous Mac OS X. > </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 que > l'UID 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 obligatoire 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 (optionnel) contient la > direction 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 <e>LINGUAS</e> contient 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èmes. ></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> > Cette fonction 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>. Cette fonction ne fait que des vérifications de > paramètres complets. > </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 que 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 créer et modifier. 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 ou 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, 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 similaires 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 paramètres 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 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 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 >de paramètres USE, vous permettant d'obtenir un système configuré exactement >comme vous le souhaiteriez. De plus vous pouvez désormais 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 évidemment 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 <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 que 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 point 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 indiquons 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, vous obtenez 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 systèmes 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 dans ce chapitre ; pour avoir >les spécifications complètes, vous pouvez consulter le site ><uri link="http://www.pathname.com/fhs/">pathname</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 la ligne <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. Faites bien attention. > <path>/usr/share/info</path> est l'<e>unique</e> emplacement officiel > pour les fichiers info GNU. Dans la mesure où 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 > installeront de la documentation supplémentaire et les placeront 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 feront probablement 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 occasionner un peu de >confusion. Notre solution consiste à tout installer dans <path>/usr</path>, ce >qui empêche les ambiguïtés et évitent une complexité inutile 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 non de paramètres ><c>USE</c>. Du coup, les ebuilds 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 permettant à un administrateur système d'installer ou >supprimer les paquets, et de 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 tâches 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 effectif. > </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 post-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>Exécute 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 l'attribut 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 sources 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 par >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 du 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> > Exécute 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 emake. 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> > Applique 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écifié 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> > Exécute <c>prepallman</c>, <c>prepallinfo</c> et <c>prepallstrip</c>. > Cette fonction 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> > Archive de manière récursive avec gzip 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> > Archive de manière récursive avec gzip 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> > Archive de manière récursive avec gzip 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 exécutez <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'à distinguer 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 permettre 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 tard) 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 <em>n'importe laquelle</em> ira très bien. ></p> > ><p> >La mention de <em>n'importe laquelle</em> 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 ç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 espère qu'ils feront : Toutes les versions >plus récentes que sys-apps/bar version 1.2 conviendront (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éma 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évision 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 sera 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 aux >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>Sauvegarder 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 local de travail (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 systè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> >Vous disposez 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 le fichier > <path>/etc/make.conf</path> ! > </ti> ></tr> > ><tr> > <ti><c>sandboxshell</c></ti> > <ti>app-shells/sandboxshell</ti> > <ti> > Ouvre 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 appliquer manuellement des corrections. > </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 permet d'obtenir 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