Go to:
Gentoo Home
Documentation
Forums
Lists
Bugs
Planet
Store
Wiki
Get Gentoo!
Gentoo's Bugzilla – Attachment 45897 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-ebuild_not_finished.xml
devrelHB6.xml (text/plain), 70.89 KB, created by
Clément VARALDI
on 2004-12-13 03:38:56 UTC
(
hide
)
Description:
gentoo-ebuild_not_finished.xml
Filename:
MIME Type:
Creator:
Clément VARALDI
Created:
2004-12-13 03:38:56 UTC
Size:
70.89 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 > vois 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>Function</th> > <th>Purpose</th> ></tr> ><tr> > <ti><c>draw_line</c></ti> > <ti> > This function draws a line consisting of a string of '=' > characters the same length as the input to the function. > </ti> ></tr> ><tr> > <ti><c>epatch</c></ti> > <ti> > This function acts as a friendlier replacement to > the <c>patch</c> command and epatch works with .bz2, .gz, .zip > and plain text patches. You do not need to specify a "-p" option, > any options that do need to be explicitly specified should be set > in <c>EPATCH_OPTS</c>. The function expects either a file or a > directory as an argument - if you specify a directory, all > patches in the form of "??_${ARCH}_..." will be applied: for a > patch to be applied, it needs to match the running architecture, > have "_all_" in the name, or <c>EPATCH_FORCE</c> must be set to > "yes". > </ti> ></tr> ><tr> > <ti><c>gen_usr_ldscript</c></ti> > <ti> > This function generates linker scripts in /usr/lib for dynamic > libraries in /lib. This fixes linking problems when a .so is in > /lib while a .a is in /usr/lib. > </ti> ></tr> ><tr> > <ti><c>have_NPTL</c></ti> > <ti> > Returns 0 if the system is using the NPTL PThreads > implementation. > </ti> ></tr> ><tr> > <ti><c>get_number_of_jobs</c></ti> > <ti> > This function checks how many CPUs are present and then sets the > correct -jX option in <c>MAKEOPTS</c>. > </ti> ></tr> ><tr> > <ti><c>mymktemp</c></ti> > <ti> > This function acts as a wrapper to mktemp when it exists, or acts > as a replacement when it does not. > </ti> ></tr> ><tr> > <ti><c>edos2unix</c></ti> > <ti> > This function performs the same action as > the <c>dos2unix</c> binary. > </ti> ></tr> ><tr> > <ti><c>egetent</c></ti> > <ti> > egetent acts as a wrapper for <c>getent</c> for Linux > or <c>nidump</c> for Mac OS X (R). > </ti> ></tr> ><tr> > <ti><c>enewuser</c></ti> > <ti> > Creates a new user. This function expects a mandatory argument > with the username, and several optional arguments can be > specified: <c>$2</c> contains a UID, pass -1 for the next > available ID; <c>$3</c> contains a shell > with <path>/bin/false</path> being the default; <c>$4</c> > contains a home directory with <path>/dev/null</path> being the > default, <c>$5</c> contains any groups to which the user should > be added, empty by default and <c>$6</c> contains a comment - the > default is "added by portage for <c>${PN}</c>". > </ti> ></tr> ><tr> > <ti><c>enewgroup</c></ti> > <ti> > Adds a new group. This function expects a mandatory argument with > the group name - an optional second argument makes the group have > a specific GID. > </ti> ></tr> ><tr> > <ti><c>make_desktop_entry</c></ti> > <ti> > Makes a desktop entry: the first argument contains the path to the > binary. Optionally, the second contains a name for the icon - the > default is <c>${PN}</c>; the third can contain a path to the icon > relative to <path>/usr/share/pixmaps</path> or a full path - the > default is <c>${PN}</c>.png; the fourth can contain an > <uri link="http://www.freedesktop.org/standards/menu-spec/">application > category</uri>, and the fifth argument contains an optional application > startup path. > </ti> ></tr> ><tr> > <ti><c>check_license</c></ti> > <ti> > Displays a license for the user to accept, if the an argument is > not specified then the license specified by <c>${LICENSE}</c> is > used. > </ti> ></tr> ><tr> > <ti><c>unpack_pdv</c></ti> > <ti> > Unpacks a pdv generated archive, the first argument must contain > the file to unpack and the second should contain "off_t" which > has to be manually generated: <c>strace -elseek ${file}</c> and > for something like "lseek(3, -4, SEEK_END)" you would pass the > value "4". > </ti> ></tr> ><tr> > <ti><c>unpack_makeself</c></ti> > <ti> > Unpacks a makeself generated archive, requires a file to unpack > as the argument. > </ti> ></tr> ><tr> > <ti><c>cdrom_get_cds</c></ti> > <ti> > Attempts to get a CD, present with files specified by the > arguments present on the system and mounted at <c>${CDROM_ROOT}</c>. > </ti> ></tr> ><tr> > <ti><c>cdrom_load_next_cd</c></ti> > <ti> > Loads the next CD once you are done with the first CD. If the > function returns, <c>${CDROM_ROOT}</c> would point to the next CD. > </ti> ></tr> ><tr> > <ti><c>strip-linguas</c></ti> > <ti> > This function makes sure that LINGUAS contains only the languages > that a package can support specified by the arguments to the > function. If the first argument is -i, then a list of .po files > in the specified directories is built and the intersection of the > lists is used. If the first argument is -u, then a list of .po > files in the specified directories is built and the union of the > lists is used. > </ti> ></tr> ></table> > ><p><b>Helper Functions provided by flag-o-matic.eclass</b></p> > ><p> >You can use the following helper functions that are provided by the >"flag-o-matic" eclass in your ebuilds. You must make sure that <c>inherit >flag-o-matic</c> is present for these functions to work. You should never >modify any compiler settings directly, instead please use flag-o-matic to >perform any actions such as filtering flags that cause trouble. ></p> > ><table> ><tr> > <th>Function</th> > <th>Purpose</th> ></tr> ><tr> > <ti><c>filter-flags</c></ti> > <ti> > This function removes particular flags from <c>C[XX]FLAGS</c> - > only complete flags are matched. > </ti> ></tr> ><tr> > <ti><c>append-flags</c></ti> > <ti> > This function adds extra flags to the existing <c>C[XX]FLAGS</c> > variables. > </ti> ></tr> ><tr> > <ti><c>replace-flags</c></ti> > <ti> > This replaces the flag specified by the first argument with the > one in the second argument in the current <c>C[XX]FLAGS</c>. > </ti> ></tr> ><tr> > <ti><c>replace-cpu-flags</c></ti> > <ti> > This replaces any -march=... or -mcpu=... flags that contain the > second argument with the first. > </ti> ></tr> ><tr> > <ti><c>replace-sparc64-flags</c></ti> > <ti> > This sets -mcpu=... to a v8 SPARC and uses the original value as > -mtune if one is not already specified. > </ti> ></tr> ><tr> > <ti><c>strip-flags</c></ti> > <ti> > Strips all flags, except those specified in <c>ALLOWED_FLAGS</c>. > </ti> ></tr> ><tr> > <ti><c>strip-unsupported-flags</c></ti> > <ti> > Strips <c>C[XX]FLAGS</c> of any flags not supported by the running > version of GCC. > </ti> ></tr> ><tr> > <ti><c>get-flag</c></ti> > <ti> > Finds a flag and outputs its value. > </ti> ></tr> ><tr> > <ti><c>is-flag</c></ti> > <ti> > This returns true if the flag is set in the > current <c>C[XX]FLAGS</c>; only complete matches are performed. > </ti> ></tr> ><tr> > <ti><c>append-ldflags</c></ti> > <ti> > This function adds extra flags to the existing <c>LDFLAGS</c> > variable. > </ti> ></tr> ><tr> > <ti><c>filter-ldflags</c></ti> > <ti> > Removes the specified flags from <c>LDFLAGS</c>, only complete > flags are matched. > </ti> ></tr> ><tr> > <ti><c>fstack-flags</c></ti> > <ti> > Appends -fno-stack-protector which suppresses -fstack-protector > and -fstack-protector-all. > </ti> ></tr> ></table> > ></body> ></subsection> > ><subsection> ><title>Rules for writing an ebuild file</title> ><body> > ><p> >Since ebuild files are really just shell scripts, you should >use your editor's shell-script mode for editing them. You should use >proper indentation, using only tab characters -- <e>no spaces</e>. Make sure >you set up your editor to put tab stops at 4 spaces. Always make sure >you use braces around your environment variables; e.g. <c>${P}</c> >instead of just <c>$P</c>. ></p> > ><p> >Long lines are wrapped with ' \', thus: ></p> > ><pre caption="Wrapping lines in ebuilds"> >./configure \ >--prefix=/usr || die "configure failed" ></pre> > ><p> >For further details, refer to <path>skel.ebuild</path> (usually >residing in <path>/usr/portage</path>). ></p> > ><p> >If you use Vim for ebuild/eclass editing, the default Gentoo vimrc >file, <path>/etc/vim/vimrc</path>, already ensures that correct >indentation and filetype settings are used for ebuild and eclass >files. For better results, including special syntax highlighting for >ebuild keywords, emerge app-vim/gentoo-syntax. ></p> > ><p> >On non-Gentoo systems, you can obtain similar results by using the >following lines in your vimrc, or better yet by installing the ><uri link="https://developer.berlios.de/projects/gentoo-syntax/">gentoo-syntax ></uri> scripts. ></p> > ><pre caption="Configuring vimrc for ebuild-editing"> >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> >If you're using Emacs, you can put the following snippet at the bottom of >.emacsrc file (for GNU Emacs) or init.el (for XEmacs) to make sure your using >the correct settings when editing anything Gentoo-related. ></p> > ><pre caption="Configuring emacsrc for ebuild-editing"> >(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> >If you're using nano, then you're in luck! Just edit <path>/etc/nanorc</path> >and uncomment the section referring to ebuild's. ></p> > ></body> ></subsection> ><subsection> ><title>USE Variables</title> ><body> > ><p> >The purpose of USE variables is to allow you to configure Portage to globally >and automatically enable or disable certain <e>optional build-time</e> >features. Here's an example. Let's say you're a GNOME fan, and you'd like any >ebuild that has the option of compiling-in optional GNOME support to do >so. In this case, you'd add <c>gnome</c> to the <c>USE</c> variable in ><path>/etc/make.conf</path>, and then Portage will automatically add optional >GNOME functionality to packages if it is available. Likewise, if you don't >want optional GNOME features to be added to your ebuilds if they are available, >simply edit <path>/etc/make.conf</path> and make sure that <c>gnome</c> is ><e>not</e> set in the <c>USE</c> variable. Gentoo Linux has an almost >overwhelming number of USE options, allowing you to have your system configured >exactly the way you want it. ></p> > ><note> >If you unset a USE variable (for example, removing <c>gnome</c> from ><c>USE</c>), this will only instruct Portage to disable <e>optional</e> >build-time support for GNOME. However, if you <c>emerge</c> an ebuild that ><e>requires</e> GNOME, the package will obviously have GNOME support enabled, >as you would expect. This also means that GNOME will be automatically >installed (as a dependency) if it hasn't been already. That's why it's always >a good idea to do an <c>emerge --pretend</c> before doing the "real" ><c>emerge</c>; that way, you'll always know exactly what you're going to get! ></note> > ><p> >In your own ebuilds, you can check whether a USE variable is set by using the ><c>use <variable></c> command. The <c>use</c> command prints out ><c><variable></c> if it is present in the user's <c>USE</c>. You would >normally use this command as follows: ></p> > ><pre caption="Finding out if a USE-flag is set"> >if use X; then > # Commands specific to X... >fi ></pre> > ><p> >USE variables can also be used to set dependencies. For example, you >may only want to require a package if a certain USE variable is set. >This is done by using the syntax <c>flag? ( mycat/mypackage )</c> in >the <c>DEPEND</c> variable for your ebuild. In this >example, <c>mycat/mypackage</c> will only be required if <c>flag</c> >is present in <c>USE</c>. It is also possible to specify what >dependency should be used if some USE flag <e>is</e> set, and what >dependency to use if it is <e>not</e> set: <c>flag? ( >mycat/mypackage)</c> and <c>!flag? ( othercat/otherpackage )</c>. In >this case, if <c>flag</c> is not set, <c>othercat/otherpackage</c> is >used instead of <c>mycat/mypackage</c>. Make sure that your ebuilds >use this syntax and not Bash IFS. Bash conditionals interfere with >Portage's dependency caching, and the use of them will break your >ebuild. ></p> > ><p> >Here's an important tip about how to use <c>USE</c>. Most of the time, >a package will have a <c>./configure</c> script used to perform configuration >steps. Generally, if your ebuild uses <c>./configure</c>, any optional >build-time functionality will be enabled or disabled by passing the appropriate >arguments to the <c>./configure</c> command. Here's the best way to handle >this: ></p> > ><pre caption="Conditionals based on USE-settings"> >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> >This approach has a very nice result. We don't have to worry about what the >default setting is for mysql or X (enable/disabled), we explicitly tell ><c>econf</c> what we want it to do based upon the <c>USE</c> variable. Not to >mention it's quite clean in terms of readability :). ></p> > ><p> >To view a continuously updated table of USE variables, please go ><uri link="http://www.gentoo.org/dyn/use-index.xml">here</uri>. ></p> > ></body> ></subsection> ></section> ><section> ><title>File system Locations</title> ><subsection> ><title>Introduction to the FHS</title> ><body> > ><p> >The file system layout standards used in Gentoo Linux closely follow the FHS, >short for <e>File system Hierarchy Standard</e>. A simplified >description of the standard is given here; for a complete >specification go to <uri>http://www.pathname.com/fhs/</uri>. ></p> > ><note> >The <path>/opt</path> hierarchy is addressed in section 3.12 of the FHS. >Section 4.4 deals with the <path>/usr/X11R6</path> directory. KDE and GNOME are >not specifically addressed, and are in fact not even mentioned in the current >version of the FHS. ></note> > ></body> ></subsection> ><subsection> ><title>How to fit your packages into the file system</title> ><body> > ><p> >Usually, if the package uses autoconf and automake, the >default installation destinations are mostly correct, with a few exceptions: ></p> > ><ul> ><li> >If you're installing a program into <path>/bin</path>, <path>/sbin</path>, ><path>/usr/bin</path>, or <path>/usr/sbin</path>, then the program's >corresponding man page should be installed into the <path>/usr/share/man</path> >tree. This can often be accomplished by specifying a <c>./configure >--mandir=/usr/share/man</c> in the ebuild. ></li> ><li> >GNU info files should always be installed to <path>/usr/share/info</path>, ><e>even if the info files are about X11, GNOME or KDE-specific programs or >tools</e>. Make a note: <path>/usr/share/info</path> is the <e>only</e> >official location for GNU info files. Since many <c>./configure</c> scripts >default to installing GNU info files in <c>/usr/info</c>, it's often necessary >to call <c>./configure</c> with the <c>--infodir=/usr/share/info</c> argument. ></li> ><li> >Documentation files are installed in <path>/usr/share/doc</path>, into a >subdirectory reflecting the name, version, and revision of the particular >program. This applies to all programs: GNOME, KDE, X11 and console alike. >However, some programs may install additional documentation and support files >into a <path>/usr/share</path> hierarchy for their own purposes. ></li> ><li> >X11-specific programs and libraries should always be installed into ><path>/usr</path>, not directly into <path>/usr/X11R6</path>. We reserve the ><path>/usr/X11R6</path> hierarchy for the X Window System, Version 11 Release 6 ><e>itself</e>. This is perhaps a more to-the-letter interpretation of the FHS >than some other distributions have made. ></li> ><li> >GNOME and KDE programs, similarly, should always be installed into ><path>/usr</path>. ></li> ></ul> > ><impo> >Some distributions choose to install GNOME and KDE into <path>/opt</path>. There >exists no standard for these desktop environments in terms of where to actually >install their files. In the interests of simplicity and consistency, we elect to >install all KDE and GNOME packages into the <path>/usr</path> hierarchy. ></impo> > ><p> >In general, you should have ebuilds install their files into the ><path>/usr</path> tree. <e>Some</e> programs can be compiled and linked with >or without GNOME, KDE, and X11 libraries, which can cause confusion. Our >solution is to install everything into <path>/usr</path> which avoids ambiguity >and needless complexity for ebuild authors. The location in which to install >a program's files should <e>not</e> depend on the presence or absence of >specific <c>USE</c> variables. Therefore, the ebuilds in the portage tree ><e>almost always</e> install into the <path>/usr</path> hierarchy exclusively. ></p> > ><note> >The <path>/opt</path> directory is reserved in Gentoo Linux for binary-only >packages. Examples include mozilla-bin, acroread, netscape and realplayer. >Packages that get installed here will usually require a ><path>/etc/env.d/foo</path> stub file. This is so that paths and additional >variables can be included into the environment. For more information on ><path>/etc/env.d</path>, please visit <uri >link="/doc/en/handbook/handbook-x86.xml?part=2&chap=5">this</uri> >document. ></note> > ></body> ></subsection> ></section> ><section> ><title>The Portage scripts and utilities</title> ><subsection> ><title>Public scripts</title> ><body> > ><p> >These are scripts used by the system-administrator to install and remove >packages, and maintain the package database. ></p> > ><p> ><c>ebuild</c> is the main engine of the Portage system; it performs all major >tasks such as unpacking, compiling, installing, merging, and unmerging >packages. It is called using the command: <c>ebuild path/to/package.ebuild >command</c>. The commands available are: ></p> > ><table> ><tr> > <th>Command</th> > <th>Description</th> > <th>Related <c>ebuild</c> Function</th> ></tr> ><tr> > <ti><c>setup</c>*</ti> > <ti> > Performs any miscellaneous commands required before the ebuild can proceed > </ti> > <ti><c>pkg_setup</c></ti> ></tr> ><tr> > <ti><c>depend</c></ti> > <ti>Displays the dependencies required to build the package</ti> > <ti>N/A</ti> ></tr> ><tr> > <ti><c>merge</c>*</ti> > <ti> > Unpacks, compiles, installs, and merges the package into your file system > </ti> > <ti>N/A</ti> ></tr> ><tr> > <ti><c>qmerge</c>*</ti> > <ti> > Merges the package into your file system, assuming that the the unpack, > compile, and install stages have already been executed > </ti> > <ti>N/A</ti> ></tr> ><tr> > <ti><c>unpack</c>*</ti> > <ti> > Unpacks the source tarballs into the work directory > </ti> > <ti><c>src_unpack</c></ti> ></tr> ><tr> > <ti><c>compile</c>*</ti> > <ti>Compiles the package</ti> > <ti><c>src_compile</c></ti> ></tr> ><tr> > <ti><c>rpm</c></ti> > <ti>Creates an RPM from the package</ti> > <ti>N/A</ti> ></tr> ><tr> > <ti><c>package</c></ti> > <ti>Creates a Gentoo <c>tbz2</c> package</ti> > <ti>N/A</ti> ></tr> ><tr> > <ti><c>prerm</c>*</ti> > <ti>Executes the pre-removal stage of the package</ti> > <ti><c>pkg_prerm</c></ti> ></tr> ><tr> > <ti><c>postrm</c>*</ti> > <ti>Executes the post-removal stage of the package</ti> > <ti><c>pkg_postrm</c></ti> ></tr> ><tr> > <ti><c>preinst</c>*</ti> > <ti>Executes the pre-installation stage of the package</ti> > <ti><c>pkg_preinst</c></ti> ></tr> ><tr> > <ti><c>postinst</c>*</ti> > <ti>Executes the post-installation stage of the package</ti> > <ti><c>pkg_postinst</c></ti> ></tr> ><tr> > <ti><c>config</c></ti> > <ti>Sets up a default configuration once the package is merged</ti> > <ti><c>pkg_config</c></ti> ></tr> ><tr> > <ti><c>touch</c>*</ti> > <ti>Updates the mtimes for each source archive in the package</ti> > <ti>N/A</ti> ></tr> ><tr> > <ti><c>clean</c>*</ti> > <ti>Cleans the work directory for the package</ti> > <ti>N/A</ti> ></tr> ><tr> > <ti><c>fetch</c>*</ti> > <ti>Fetches the package source tarballs</ti> > <ti>N/A</ti> ></tr> ><tr> > <ti><c>digest</c>*</ti> > <ti>Creates a digest file for the package</ti> > <ti>N/A</ti> ></tr> ><tr> > <ti><c>install</c>*</ti> > <ti>Installs the package into the image directory</ti> > <ti><c>src_install</c></ti> ></tr> ><tr> > <ti><c>unmerge</c></ti> > <ti>Unmerges the package from your file system</ti> > <ti>N/A</ti> ></tr> ></table> > ><note> >Commands with an asterisk (*) are normally only used by the developer. ></note> > ><p> ><c>emerge</c> recursively merges a package and all of its dependencies into >your file system. This command has many options, try <c>emerge --help</c> for >a list of them. ></p> > ><p> ><c>env-update</c> updates the configuration files (including, but not limited >to <path>/etc/ld.so.conf</path> and <path>/etc/profile.env</path>) to include >changes made by installed packages. ></p> > ></body> ></subsection> ><subsection> ><title>Private Scripts and Commands</title> ><body> > ><p> >These are scripts you can use in your ebuild files to perform common tasks. ></p> > ><p> >For you down and dirty people, look at the scripts themselves in ><path>/usr/lib/portage/bin</path>. ></p> > ><table> ><tr> > <th>Command</th> > <th>Default Value</th> > <th>Description</th> > <th>Example</th> ></tr> ><tr> > <ti><c>diropts</c></ti> > <ti>-m0755</ti> > <ti>Sets the options used when running <c>dodir</c></ti> > <ti><c>diropts -m0750</c></ti> ></tr> ><tr> > <ti><c>dobin</c></ti> > <ti>N/A</ti> > <ti>Installs the specified binaries into <path>DESTTREE/bin</path></ti> > <ti><c>dobin wmacpi</c></ti> ></tr> ><tr> > <ti><c>docinto</c></ti> > <ti><path>""</path></ti> > <ti> > Sets the relative subdir (<e>DOCDESTTREE</e>) used by <c>dodoc</c> > </ti> > <ti><c>docinto examples</c></ti> ></tr> ><tr> > <ti><c>dodir</c></ti> > <ti>N/A</ti> > <ti>Creates a directory, handling ${D} transparently</ti> > <ti><c>dodir /usr/lib/newpackage</c></ti> ></tr> ><tr> > <ti><c>dodoc</c></ti> > <ti>N/A</ti> > <ti> > Installs the specified files into the package's documentation directory > (<path>/usr/share/doc/${PF}/DOCDESTTREE</path>) (see <c>docinto</c>) > </ti> > <ti><c>dodoc README *.txt</c></ti> ></tr> ><tr> > <ti><c>doexe</c></ti> > <ti>N/A</ti> > <ti> > Installs the specified files with mode <e>EXEOPTIONS</e> (see > <c>exeopts</c>) into <path>EXEDESTTREE</path> (see <c>exeinto</c>) > </ti> > <ti><c>doexe ${FILESDIR}/quake3</c></ti> ></tr> ><tr> > <ti><c>dohard</c></ti> > <ti>N/A</ti> > <ti>Creates a hard link, handling ${D} transparently</ti> > <ti><c>dohard ls /bin/dir</c></ti> ></tr> ><tr> > <ti><c>dohtml</c></ti> > <ti>N/A</ti> > <ti> > Installs the specified files and directories into > <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> > Installs the specified files into /usr/share/info, then compresses them > with gzip > </ti> > <ti><c>doinfo doc/*.info</c></ti> ></tr> ><tr> > <ti><c>doins</c></ti> > <ti>N/A</ti> > <ti> > Installs the specified files with mode <c>INSOPTIONS</c> (see > <c>insopts</c>) into <path>INSDESTTREE</path> (see <c>insinto</c>) > </ti> > <ti><c>doins *.png icon.xpm</c></ti> ></tr> ><tr> > <ti><c>dolib</c></ti> > <ti>N/A</ti> > <ti> > Installs the specified libraries into <path>DESTTREE/lib</path> with mode > 0644 > </ti> > <ti><c>dolib *.a *.so</c></ti> ></tr> ><tr> > <ti><c>dolib.a</c></ti> > <ti>N/A</ti> > <ti> > Installs the specified libraries into <path>DESTTREE/lib</path> with mode > 0644 > </ti> > <ti><c>dolib.a *.a</c></ti> ></tr> ><tr> > <ti><c>dolib.so</c></ti> > <ti>N/A</ti> > <ti> > Installs the specified libraries into <path>DESTTREE/lib</path> with mode > 0755 > </ti> > <ti><c>dolib.so *.so</c></ti> ></tr> ><tr> > <ti><c>doman</c></ti> > <ti>N/A</ti> > <ti> > Installs the specified files into <path>/usr/share/man/manX</path>, > according to the suffix of the file (file.1 will go into <path>man1</path>) > </ti> > <ti><c>doman *.1 *.5</c></ti> ></tr> ><tr> > <ti><c>dosbin</c></ti> > <ti>N/A</ti> > <ti> > Installs the files into <path>DESTTREE/sbin</path>, making sure they are > executable > </ti> > <ti><c>dosbin ksymoops</c></ti> ></tr> ><tr> > <ti><c>dosym</c></ti> > <ti>N/A</ti> > <ti>Creates a symlink, handles ${D} transparently</ti> > <ti><c>dosym gzip /bin/zcat</c></ti> ></tr> ><tr> > <ti><c>emake</c></ti> > <ti>N/A</ti> > <ti> > Runs make with <c>MAKEOPTS</c>. Some packages cannot be made in > parallel; use <c>emake -j1</c> instead. If you need to pass any > extra arguments to make, simply append them onto the emake > command. Users can set the <c>EXTRA_EMAKE</c> environment variable > to pass extra flags to emake. > </ti> > <ti><c>emake</c></ti> ></tr> ><tr> > <ti><c>exeinto</c></ti> > <ti><path>/</path></ti> > <ti>Sets the root (<e>EXEDESTTREE</e>) for the <c>doexe</c> command</ti> > <ti><c>exeinto /usr/lib/${PN}</c></ti> ></tr> ><tr> > <ti><c>exeopts</c></ti> > <ti>-m0755</ti> > <ti>Sets the options used when running <c>doexe</c></ti> > <ti><c>exeopts -m1770</c></ti> ></tr> ><tr> > <ti><c>fowners</c></ti> > <ti>N/A</ti> > <ti> > Applies the specified ownership to the specified file via the chown > command, handles ${D} transparently > </ti> > <ti><c>fowners root:root /sbin/functions.sh</c></ti> ></tr> ><tr> > <ti><c>fperms</c></ti> > <ti>N/A</ti> > <ti> > Applies the specified permissions to the specified file via the chmod > command, handles ${D} transparently > </ti> > <ti><c>fperms 700 /var/consoles</c></ti> ></tr> ><tr> > <ti><c>insinto</c></ti> > <ti><path>/usr</path></ti> > <ti>Sets the root (<e>INSDESTTREE</e>) for the <c>doins</c> command</ti> > <ti><c>insinto /usr/include</c></ti> ></tr> ><tr> > <ti><c>insopts</c></ti> > <ti>-m0644</ti> > <ti>Sets the options used when running <c>doins</c></ti> > <ti><c>insopts -m0444</c></ti> ></tr> ><tr> > <ti><c>into</c></ti> > <ti><path>/usr</path></ti> > <ti> > Sets the target prefix (<path>DESTTREE</path>) for all the 'do' commands > (like <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>Sets the options used when running <c>dolib</c></ti> > <ti><c>libopts -m0555</c></ti> ></tr> ><tr> > <ti><c>newbin</c></ti> > <ti>N/A</ti> > <ti> > Wrapper around <c>dobin</c> which installs the specified binary > transparently renaming to the second argument > </ti> > <ti><c>newbin ${FILESDIR}/vmware.sh vmware</c></ti> ></tr> ><tr> > <ti><c>newdoc</c></ti> > <ti>N/A</ti> > <ti> > Wrapper around <c>dodoc</c> which installs the specified file transparently > renaming to the second argument > </ti> > <ti><c>newdoc README README.opengl</c></ti> ></tr> ><tr> > <ti><c>newexe</c></ti> > <ti>N/A</ti> > <ti> > Wrapper around <c>doexe</c> which installs the specified file transparently > renaming to the second argument > </ti> > <ti><c>newexe ${FILESDIR}/xinetd.rc xinetd</c></ti> ></tr> ><tr> > <ti><c>newins</c></ti> > <ti>N/A</ti> > <ti> > Wrapper around <c>doins</c> which installs the specified file transparently > renaming to the 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> > Wrapper around <c>doman</c> which installs the specified file transparently > renaming to the second argument > </ti> > <ti><c>newman xboing.man xboing.6</c></ti> ></tr> ><tr> > <ti><c>newsbin</c></ti> > <ti>N/A</ti> > <ti> > Wrapper around <c>dosbin</c> which installs the specified file transparently > renaming to the second argument > </ti> > <ti><c>newsbin strings strings-static</c></ti> ></tr> ><tr> > <ti><c>prepall</c></ti> > <ti>N/A</ti> > <ti> > Runs <c>prepallman</c>, <c>prepallinfo</c> and <c>prepallstrip</c>. Also > ensures all libraries in <path>/opt/*/lib</path>, <path>/lib</path>, > <path>/usr/lib</path> and <path>/usr/X11R6/lib</path> are executable. also > moves any stray aclocal macros into <path>/usr/share/aclocal</path> > </ti> > <ti><c>prepall</c></ti> ></tr> ><tr> > <ti><c>prepalldocs</c></ti> > <ti>N/A</ti> > <ti> > Recursively gzips all doc files in <path>/usr/share/doc</path>, > transparently fixing up any symlink paths > </ti> > <ti><c>prepalldocs</c></ti> ></tr> ><tr> > <ti><c>prepallinfo</c></ti> > <ti>N/A</ti> > <ti>Recursively gzips all info files in <path>/usr/share/info</path></ti> > <ti><c>prepallinfo</c></ti> ></tr> ><tr> > <ti><c>prepallman</c></ti> > <ti>N/A</ti> > <ti> > Recursively gzips all man pages in <path>/opt/*/man/*</path>, > <path>/usr/share/man/*</path>, <path>/usr/local/man/*</path>, > <path>/usr/X11R6/share/man/*</path> and transparently fixes up any symlink > paths > </ti> > <ti><c>prepallman</c></ti> ></tr> ></table> > ></body> ></subsection> ></section> ><section> ><title>Package Dependencies</title> ><subsection> ><title>Why dependencies are important</title> ><body> > ><p> >Portage is more than just a convenience script that gives you a unified >way to build any one project (program, library) from source. It will also >fetch and install any necessary dependencies if you take care to specify >these in your ebuild. ></p> > ><p> >In the official ebuilds, all dependencies have already been specified, >so when you issue <c>emerge net-www/mozilla/mozilla-1.0</c>, Portage will >insure that all libraries necessary for Mozilla to build and run are >properly installed before Mozilla itself is built. ></p> > ><p> >Portage even distinguishes between build-time dependencies and run-time >dependencies. (Caveat: Currently, Portage installs all build-time and run-time >dependencies and leaves it at that. At a later stage, it will be possible to >trim your installation so that only the run-time dependencies are left >installed). ></p> > ></body> ></subsection> ><subsection> ><title>How to Specify Dependencies in Your ebuild Files (a.k.a. DEPEND Atoms)</title> ><body> > ><p> >The <c>DEPEND</c> variable inside your <path>foo-x.y.z.ebuild</path> tells >Portage about which packages are needed to build <path>foo</path>. The ><c>RDEPEND</c> variable specifies which packages are needed for <path>foo</path> >to run. ></p> > ><pre caption="Depend example"> >DEPEND="virtual/glibc > sys-libs/zlib" >RDEPEND="virtual/glibc" ></pre> > ><p> >This tells Portage that to build <path>foo-x.y.z</path>, the packages ><path>virtual/glibc</path> (more on virtuals in a bit) and ><path>sys-libs/zlib</path> are needed. It does not say anything about which >version of glibc or zlib that are needed, which means "anything goes". ></p> > ><p> >The "anything goes" is of course a bit scary, and will not work in the general >case. But for central libraries like glibc, which strives very hard to be 100% >binary compatible all the time, it actually works. For other libraries, we can >of course specify version dependencies. ></p> > ><pre caption="Version example"> >>=sys-apps/bar-1.2 >=sys-apps/baz-1.0 ></pre> > ><p> >>= and = do what you would expect; sys-apps/bar version 1.2 or newer is okay >(this means that sys-apps/bar-2.0 is okay), while sys-apps/baz version 1.0 is >the only version that is accepted. For more information on the version schema of >packages, see the section above on <uri link="#doc_chap2_sect2">Naming ebuild >Files</uri>. ></p> > ><p> >Other methods of specifying version dependencies are as follows: ></p> > ><pre caption="Specifying version dependencies"> >~sys-apps/qux-1.0 >=sys-apps/foo-1.2* >!sys-libs/gdbm ></pre> > ><p> >~sys-apps/qux-1.0 will select the newest portage revision of qux-1.0. ></p> > ><p> >=sys-apps/foo-1.2* will select the newest member of the 1.2 series, but will >ignore 1.3 and later/earlier series. That is, foo-1.2.3 and foo-1.2.0 are both >valid, while foo-1.3.3, foo-1.3.0, and foo-1.1.0 are not. ></p> > ><p> >!sys-libs/gdbm will prevent this package from being emerged while gdbm is >already emerged. ></p> > ><note> >For all the latest details about these DEPEND Atoms, please see the section 5 >manpage on ebuilds: <c>man 5 ebuild</c>. ></note> > ></body> ></subsection> ></section> > ><section> ><title>Testing and deploying</title> ><subsection> ><title>ChangeLog</title> ><body> > ><p> >Whenever you update a (or write a new) ebuild, you must also update its (or >create a new) ChangeLog. The <path>skel.ChangeLog</path> contains a sample >ChangeLog that you can use as a basis. ></p> > ><p> >The purpose of the ChangeLog is to document <e>what</e> is being done, ><e>why</e> it is being done, and by <e>whom</e>. This allows both >developers and users to trace the changes made in an easy way. ></p> > ><p> >The ChangeLog is primarily targeted at users, so be sure to keep your >writing short, to the point, and avoid getting verbose about the internal >technical details. ></p> > ></body> ></subsection> > ><subsection> ><title>Storing your own ebuilds locally</title> ><body> > ><p> >In order to be able to test your ebuilds and let Portage know about them, you >must place those in a known directory. Portage will use the ><c>PORTDIR_OVERLAY</c> variable which you can define in ><path>/etc/make.conf</path>. You should set this variable to your directory >(e.g. <path>/usr/local/portage</path>). ></p> > ><p> >In that directory, you must use the same structure (and categories) as in ><path>/usr/portage</path>. ></p> > ><p> >Using this <c>PORTDIR_OVERLAY</c>, your ebuilds remain on your system, even >after an <c>emerge sync</c>, and they are still known to Portage. ></p> > ></body> ></subsection> > ><subsection> ><title>Useful testing tools</title> ><body> > ><p> >We have a few useful tools to help you with writing and maintaining your >ebuilds. ></p> > ><warn> ><c>lintool</c> is broken. Use repoman instead. ></warn> > ><table> ><tr> > <th>Tool</th> > <th>Package</th> > <th>Description</th> ></tr> ><tr> > <ti><c>repoman</c></ti> > <ti>sys-apps/portage</ti> > <ti> > Developer-only tool to assist with the CVS checkin procedure. It does a > lot of common QA and tries to make sure that files added to cvs will not > break the portage tree. > </ti> ></tr> ><tr> > <ti><c>ccache</c></ti> > <ti>dev-util/ccache</ti> > <ti> > Tool that keeps pre-processed files so that recompilation gets done > <e>much</e> faster. Be sure to add <c>ccache</c> to the <c>FEATURES</c> > variable in <path>/etc/make.conf</path>! > </ti> ></tr> ><tr> > <ti><c>sandboxshell</c></ti> > <ti>app-shells/sandboxshell</ti> > <ti> > Launch a shell that creates a sandbox environment. Useful for entering the > same environment that portage builds packages inside of and debugging > things by hand. > </ti> ></tr> ><tr> > <ti><c>echangelog</c></ti> > <ti>app-portage/gentoolkit-dev</ti> > <ti>Can create a new ChangeLog or add an entry to an existing one.</ti> ></tr> ><!-- ><tr> > <ti><c>gentool-bump-revision</c></ti> > <ti>app-portage/gentoolkit</ti> > <ti> > Developer-only tool that bumps the revision number, adds the new revision > to CVS, removed the old revision and updates the ChangeLog accordingly. > </ti> ></tr> >--> ><tr> > <ti><c>qpkg</c></ti> > <ti>app-portage/gentoolkit</ti> > <ti>A tool to gather misc information about installed packages.</ti> ></tr> ></table> > ></body> ></subsection> ></section> ></sections>
<b>You cannot view the attachment while viewing its details because your browser does not support IFRAMEs. <a href="attachment.cgi?id=45897">View the attachment on a separate page</a>.</b>
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
