Gentoo Logo

[ << ] [ < ] [ Sommaire ] [ > ] [ >> ]


1. Guide pour les ebuilds

Table des matières :

1.a. L'arbre de Portage

Introduction

L'arbre de Portage se trouve en général dans /usr/portage 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 util-linux-2.11y.ebuild dans le répertoire /usr/portage/sys-apps/util-linux. Il peut y avoir plusieurs autres versions d'ebuilds pour util-linux à côté de util-linux-2.11y.ebuild. C'est dû au fait que tous les ebuilds pour un paquet particulier (quelle que soit la version) partagent le même répertoire ma_categorie/mon_paquet dans /usr/portage, à moins que vous ayez des surcouches « overlays » installées.

Récupérer une version de l'arbre de Portage avec CVS

Si vous n'êtes pas familier avec le fonctionnement de CVS, vous pouvez lire le tutoriel CVS pour plus d'informations.

L'arbre de Portage se trouve dans le module gentoo-x86 de l'arbre de Gentoo Linux. Pour récupérer ce module (environ 350 Mo), vous devez tout d'abord préparer CVS, comme spécifié dans le guide cité plus haut, puis récupérer le module gentoo-x86.

Ce qu'on (ne) peut (pas) mettre dans l'arbre de Portage

Avant d'écrire un ebuild, vérifiez sur bugs.gentoo.org qu'il n'en existe pas déjà un, mais qui n'aurait pas encore été mis dans Portage. Allez sur bugs.gentoo.org, choisissez query et sélectionnez Advanced Search. Pour le produit, prenez Gentoo Linux et comme composant, ebuilds. Dans le champ réservé à la recherche écrivez le nom de l'ebuild, puis comme statut, selectionnez NEW, ASSIGNED, REOPENED et RESOLVED (RESOLVED est important ici), puis envoyez la requête. Pour les fainéants, cliquez directement ici.

En règle générale, l'arbre de Portage ne doit être utilisé que pour stocker des fichiers .ebuild, 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 /usr/portage/macat/monpaquet/files pour garder une organisation des répertoires /macat/monpaquet la plus propre et ordonné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, vous ne devriez pas ajouter des fichiers binaires (non-ASCII) au CVS dans l'arbre de Portage. 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 -kb comme suit :

Exemple de code 1.1 : Ajouter un binaire au CVS

# cvs add -kb monimage.png

L'option -kb indique à CVS que monimage.png est un fichier binaire et qu'il doit être traité de manière particulière. Par exemple, lui demander 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 ne devront pas ê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.

Souvenez-vous que les paquets que vous soumettez doivent être prêts à l'utilisation de manière autonome 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 application a un problème et que vous n'êtes pas sûr de la solution pour le faire fonctionner, vous pouvez vous inspirer de ce que les responsables d'autres distributions ont mis en place pour obtenir un paquet fonctionnel. Vous pouvez regarder chez Mandriva ou Debian ou Fedora pour avoir de bons exemples.

Quand ils effectuent une soumission au CVS, tous les développeurs doivent utiliser repoman commit en lieu et place de cvs commit pour soumettre leurs ebuilds. Avant de faire une soumission, vous devez exécuter la commande repoman full pour vous assurer que vous n'avez rien oublié.

Politique de soumission au CVS

  • Toujours exécuter repoman scan avant de soumettre son travail ;
  • Exécutez repoman full avant de faire une soumission ;
  • Toujours vérifier que package.mask est en règle en effectuant un emerge --pretend monpaquet avant de le soumettre et vérifiez qu'il n'y a aucun conflit ;
  • Toujours mettre à jour le ChangeLog avant de faire une soumission ;
  • Toujours mettre à jour en premier package.mask avant de mettre à jour le paquet concerné. Il peut y avoir des conflits lors de la soumission de package.mask ;
  • 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 package.mask, puis soumettre l'ebuild, le ChangeLog et le metadata.xml d'une traite. Sauf si vous souhaitez corrompre les installations des utilisateurs...

Le répertoire de destination pour les fichiers

Comme remarqué précédemment, dans chaque sous-répertoire de paquet, il y a un répertoire files/. 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 demander 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 monpaquet-1.0-gentoo.diff ou plus simplement 1.0-gentoo.diff. Remarquez la présence de l'extension gentoo 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.

Préfixez ou suffixez (comme par exemple monpaquet-1.0) tous les fichiers que vous mettez dans le répertoire files/ 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.

Si plusieurs fichiers doivent aller dans le répertoire files/, vous pouvez créer des sous-répertoires comme par exemple files/1.0/ 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.

1.b. Scripts ebuild

Introduction

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 une invite de commande. Un des principes importants dans la conception 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.

Les scripts ebuild sont interprétés par les commandes ebuild et emerge. Il faut imaginer la commande ebuild 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é emerge est un outil de haut niveau par rapport à ebuild. Il a la capacité d'installer automatiquement les dépendances nécessaires et d'effectuer des vérifications d'installation (avec pretend) pour que l'utilisateur puisse voir quels sont les ebuilds qui seront installés et s'arrêter là. En général, emerge vole la vedette à ebuild dans tous les domaines, sauf un. Avec ebuild, 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.

Nommer les fichiers ebuild

Le nom des fichiers ebuilds comporte quatre sous-sections logiques :

pkg-ver{_suf{#}}{-r#}.ebuild

Note : Les crochets ({}) délimitent des champs optionnels et n'apparaissent pas dans le nom final pour le paquet. # représente un entier positif différent de zéro.

La première sous-section, pkg, est le nom du paquet qui doit toujours contenir des caractères choisis parmi les minuscules, les chiffres de 0 à 9, le tiret -, le soulignement _ ou le plus +. Par exemple, on a util-linux, sysklogd et gtk+. Nous avons quelques paquets dans Portage qui ne suivent pas cette règle, mais les vôtres devront la respecter.

La seconde sous-section ver est la version du paquet qui doit normalement être la même que la version de l'archive source principale. La version est en général constituée de deux ou trois (ou plus) nombres séparés par un point, comme 1.2 ou 4.5.2 et peuvent comporter une lettre seule suivant immédiatement le dernier chiffre. Par exemple, 1.4b ou 2.6h. La version du paquet est liée au nom du paquet par un tiret. Par exemple, vous aurez foo-1.0 ou bar-2.4.6.

Important : Si vous pensez utiliser une lettre à la fin de la version du paquet, n'oubliez pas que ce caractère ne doit pas être utilisé pour signifier le statut alpha ou beta d'un paquet, dans la mesure ou les alpha et beta sont des pré-sorties et les révisions ultérieures sont des nouvelles versions. 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.

La troisième sous-section, {_suf{#}}, est optionnelle et peut contenir un suffixe pré-défini parmi ceux listés (du plus vieux au plus récent) ci-dessous :

Suffixe Sens
_alpha Sortie de type Alpha
_beta Sortie de type Beta
_pre Pré-sortie
_rc Candidat à la sortie
(aucun) Sortie officielle
_p Niveau de correctif (normalement suivi d'un entier)

Tous ces suffixes doivent être suivis immédiatement d'un entier positif non nul, comme par exemple linux-2.4.0_pre10. En supposant des versions identiques, les suffixes sont ordonnés ainsi (le premier étant le plus vieux) : _alpha < _beta < _pre < _rc < (aucun suffixe) < _p.

En comparant deux suffixes identiques avec les entiers qui les suivent, celui qui a le numéro le plus grand sera considéré comme plus récent. Par exemple, foo-1.0_alpha4 est plus récent que foo-1.0_alpha3.

La quatrième sous-section dans le nom du paquet est le numéro de révision spécifique à Gentoo Linux ({-r#}). Cette sous-section comme le suffixe est optionnelle. # est un entier positif non nul, ce qui donne par exemple paquet-4.5.3-r3.

Le numéro de révision est indépendant de la version de l'archive source et est utilisé pour informer les utilisateurs qu'une révision provenant de Gentoo Linux, pour un paquet particulier, est disponible. Les sorties initiales d'ebuilds ne doivent pas avoir de numéro de révision. Par exemple, paquet-4.5.3 est considéré par Portage comme ayant un numéro de révision de zéro. Cela signifie que le décompte se fait ainsi : 1.0 (version initiale), 1.0-r1, 1.0-r2, etc.

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. N'oubliez jamais de laisser une mention de vos modifications dans le fichier ChangeLog, vous pourriez avoir de sérieux problèmes si vous ne le faites pas (par exemple votre accès CVS pourrait être révoqué).

Et évidemment nous avons une cinquième partie dans le nom de l'ebuild... l'extension .ebuild elle-même.

Le contenu d'un fichier ebuild

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 :man 5 ebuild.

En-têtes

Quand vous soumettez vos ebuilds, les en-têtes doivent être strictement identiques au contenu du fichier /usr/portage/header.txt. Ne les modifiez en aucune façon et vérifiez bien que la ligne $Header: $ est telle quelle.

Les trois premières lignes doivent être identiques à :

Exemple de code 2.1 : En-tête valide

# Copyright 1999-2005 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

Les variables

La première partie de tous les fichiers ebuild est constituée d'un certain nombre de variables. Pour plus d'information sur ces variables, consultez le guide de développement.

Les fonctions

Un certain nombre de fonctions que vous pouvez définir dans vos fichiers ebuilds permettent de contrôler la construction et le processus d'installation de votre paquet.

Fonction Objectif
pkg_setup Utilisez cette fonction pour effectuer n'importe quel type de tâche qui soit un pré-requis à la construction. Cela inclut la vérification de l'existence d'un fichier de configuration par exemple.
pkg_nofetch 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 RESTRICT="fetch". Vous pouvez uniquement afficher des messages avec cette fonction, jamais d'appel à la fonction die.
src_unpack 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 A. Le répertoire de travail initial est définit par WORKDIR.
src_compile Utilisez cette fonction pour configurer et construire le paquet. Le répertoire initial de travail est S.
src_install Utilisez cette fonction pour installer le paquet dans une image dans D. Si le paquet utilise automake, vous pouvez simplement effectuer un emake DESTDIR=${D} install. Assurez-vous que votre paquet installe tous ses fichiers en utilisant D comme racine ! Le répertoire initial de travail est S.
src_test Cette fonction n'est exécutée que si vous avez initialisé la variable FEATURES="test" et si RESTRICT="test" 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} 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.
pkg_preinst Les commandes dans cette fonction sont lancées juste avant la fusion de l'image du paquet dans le système de fichiers.
pkg_postinst Les commandes dans cette fonction sont lancées juste après la fusion de votre image de paquet dans le système de fichiers.
pkg_prerm Les commandes dans cette fonction sont lancées juste avant la suppression d'un paquet du système de fichiers.
pkg_postrm Les commandes dans cette fonction sont lancées juste après la suppression d'un paquet du système de fichiers.
pkg_config Vous utiliserez cette fonction pour mettre en œuvre une configuration initiale d'un paquet après qu'il ait été installé. Toutes les chemins des répertoires dans cette fonction doivent être préfixés de ROOT qui indique le répertoire racine (il se peut que ce ne soit pas /.) Cette fonction est uniquement exécutée si l'utilisateur lance : emerge --config =${PF}.

Les fonctions utilitaires

Vous pouvez également utiliser les fonctions suivantes dans vos ebuilds.

Fonction Objectif
use Vérifier si une ou plusieurs variables USE sont sélectionnées. Pour les variables sélectionnées, la fonction renverra "vrai". Dans tous les cas, rien ne sera affiché sur la sortie standard. Pour une sortie plus verbeuse, utilisez usev qui affichera les options USE qui ont été sélectionnées.
has_version Retourne 1 si le système a la version requise d'un certain paquet. Utilisez-le ainsi : has_version >=sys-libs/glibc-2.3.0.
best_version Retourne le couple categorie/paquet-version d'un couple categorie/paquet demandé. Utilisez-le ainsi : best_version x11-libs/gtk+extra.
use_with Cette fonction vérifie si un paramètre USE a été défini et retourne "--with-foobar" ou "--without-foobar" selon le cas. Si vous ne donnez qu'un seul argument, cet argument sera à la fois paramètre USE et with(out)-string. Sinon le premier argument sera le paramètre USE, et le second sera le with(out)-string. Par exemple, use_with truetype freetype retournera "--with-freetype" si truetype est dans les paramètres USE.
use_enable Même fonction que use_with, mais retourne "--enable-foobar" ou "--disable-foobar" selon le cas.
check_KV 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'une version de noyau dans votre script, utilisez la variableKV qui est automatiquement définie par Portage. Sur un système utilisant gentoo-sources-2.4.20-r6, KV devra avoir la valeur "2.4.20".
keepdir Crée (si besoin) un fichier .keep dans un répertoire donné afin qu'il ne soit pas supprimé automatiquement. Ne jamais créer de fichier .keep soi-même. Si Portage change le fonctionnement de keepdir, créer un tel fichier soi-même pourrait casser le paquet.
econf Exécute ./configure avec les changements de répertoires nécessaires (prefix, host, mandir, infodir, datadir, sysconfdir, localstatedir). Vous pouvez éventuellement lui passer des arguments supplémentaires pour ./configure en les donnant lors de l'appel d'econf et les utilisateurs peuvent également utiliser la variable EXTRA_ECONF s'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.
einstall Exécute make install 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 à einstall. Notez que la méthode utilisée de manière préférentielle pour installer un paquet est d'utiliser la commande emake install DESTDIR="${D}" et non einstall. Cette commande n'est en fait qu'une alternative aux fichiers make défectueux.
die Avorte le processus en cours. Il indiquera à l'utilisateur les données passées en argument. Ne pas négliger l'utilisation de message passés en arguments à die si vous faites plusieurs appels à die 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 le paquet a échoué.
elog Informe l'utilisateur d'un événement important. L'argument passé à elog est le message qui sera donné à l'utilisateur. N'utilisez pas elog pour afficher des bannières comme "*************************************". Le fait même d'utiliser elof est suffisant pour attirer l'attention de l'utilisateur. Le message est aussi sauvegardé dans un fichier de traçage (« log ») en utilisant le système « ELOG » de Portage.
einfo Affiche des informations moins importantes qui ne seront pas sauvegardés dans un fichier de traçage (« log »).

Fonctions utilitaires proposées par eutils.eclass

Vous pouvez utiliser les fonctions suivantes proposées par l'eclass "eutils" de vos ebuilds. Vous devez vous assurer que inherit eutils est présent dans votre ebuild pour pouvoir utiliser ces fonctions.

Fonction Objectif
epatch Cette fonction ressemble un peu à la commande patch mais a l'avantage de fonctionner avec des correctifs aux formats .bz2, .gz, .zip et fichiers 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 EPATCH_OPTS. 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 EPATCH_FORCE à "yes".
gen_usr_ldscript Cette fonction génère des scripts de liens dans /usr/lib pour les bibliothèques dynamiques dans /lib. Cela résoud les problèmes de liens lorsqu'un .so est dans /lib alors qu'un .a est dans /usr/lib.
edos2unix Cette fonction effectue la même tâche que le binaire dos2unix.
egetent egetent est une abstraction de getent sous Linux ou nidump sous Mac OS X.
enewuser 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 : $2 contient un UID. Mettre -1 pour que l'UID prenne le prochain ID disponible. $3 contient un shell. Mettre -1 pour que prendre le shell par défaut. $4 contient le répertoire utilisateur avec /dev/null comme répertoire par défaut. $5 contient tous les groupes auquel l'utilisateur doit être ajouté, vide par défaut et $6 contient les éventuels paramètres à passer à la commande useradd lors de la création de l'utilisateur.
enewgroup Ajoute un nouveau groupe. Cette fonction prend pour paramètre obligatoire le nom du groupe et comme paramètre optionnel le GID souhaité pour ce groupe.
make_desktop_entry 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 ${PN} ; le troisième argument peut contenir le chemin vers une icône relatif à /usr/share/pixmaps ou en donnant le chemin complet à partir de la racine, par défaut, ${PN}.png ; le quatrième peut contenir une catégorie d'application et enfin le cinquième argument (optionnel) contient le chemin de lancement de l'application.
check_license 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 ${LICENSE}.
unpack_pdv 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 : strace -elseek${file} et pour obtenir quelque chose du genre « lseek(3, -4, SEEK_END) » vous devriez lui passer comme valeur « 4 ».
unpack_makeself Désarchive une archive créée avec makeself. L'argument nécessaire sera le nom du fichier à désarchiver.
cdrom_get_cds Essaie d'obtenir un CD qui possède les fichiers spécifiés en argument et qui est monté sur ${CDROM_ROOT}.
cdrom_load_next_cd Charge le CD suivant une fois que vous en avez fini avec le premier CD. Si la fonction est lancée, ${CDROM_ROOT} devra pointer vers le CD suivant.
strip-linguas Cette fonction s'assure que LINGUAS 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 -u est passé en premier argument, alors la liste des fichiers .po des répertoires spécifiés est construite et l'union des listes est utilisée.

Fonctions utilitaires proposées par flag-o-matic.eclass

Vous pouvez utiliser les fonctions suivantes proposées par l'eclass « flag-o-matic » dans vos ebuilds. Vous devez vous assurer que inherit flag-o-matic 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.

Fonction Objectif
filter-flags Cette fonction supprime un paramètre particulier de C[XX]FLAGS. Seuls les paramètres complets sont vérifiés.
append-flags Cette fonction ajoute un paramètre supplémentaire à ceux définis dans les variables C[XX]FLAGS.
replace-flags Cette fonction remplace un paramètre spécifié en premier argument par un autre donné en second argument, dans les variables actuelles de C[XX]FLAGS.
replace-cpu-flags Cette fonction nécessite deux arguments. Il remplace une valeur de type mtune/march/mcpu par une autre (Par exemple, « replace-cpu-flags 'i686' 'i586' » remplacera -mtune/-march/-mcpu=i686 par -mtune/-march/-mcpu=i586).
strip-flags Enlève tous les paramètres sauf ceux spécifiés dans ALLOWED_FLAGS.
strip-unsupported-flags Enlève de C[XX]FLAGS tous les paramètres non supportés par la version utilisée de GCC.
get-flag Trouve un paramètre et retourne sa valeur.
is-flag Retourne vrai si le paramètre est déclaré dans les variables actuelles C[XX]FLAGS. Cette fonction ne fait que des vérifications de paramètres complets.
append-ldflags Cette fonction ajoute des paramètres supplémentaires à la variable LDFLAGS.
filter-ldflags Enlève les paramètres spécifiés de LDFLAGS et ne vérifie que les paramètres complets.
fstack-flags Utilise -fno-stack-protector, ce qui supprime -fstack-protector et -fstack-protector-all.

Les fonctions d'assistance fournies par toolchain-funs.eclass

Vous pouvez aussi utiliser les fonctions suivantes fournies par l'eclass "toolchain-funcs". Vous devez vous assurer que inherit toolchain-funcs est présent pour que ces fonctions puissent fonctionner. Ne spécifiez jamais d'options du compilateur ou de binutils directement, utilisez plutôt les fonctions de toolchain-funcs.

Le but des fonctions ci-dessous est de permettre la compilation croisée et l'utilisation du compilateur icc. Elles devraient être appelées quand un paquet utilise directement gcc, g++, ld, ranlib ou un des outils ci-dessous. En général, les paquets qui utilisent les outils de configuration automatique détectent la compilation croisée.

Fonction Objectif
tc-getAR Retourne le nom du programme archiveur
tc-getAS Retourne le nom de l'assembleur
tc-getCC Retourne le nom du compilateur C
tc-getCXX Retourne le nom du compilateur C++
tc-getLD Retourne le nom de l'éditeur de liens
tc-getNM Retourne le nom de l'inspecteur de symboles
tc-getRANLIB Retourne le nom de l'indexeur d'archive
tc-getF77 Retourne le nom du compilateur Fortran
tc-getGCJ Retourne le nom du compilateur Java
tc-getBUILD_CC Retourne le nom du compilateur C pour la compilation
tc-is-cross-compiler Indique si on fait une compilation croisée
gcc-fullversion Retourne la version telle que reçue par la commande $($CC -dumpversion)
gcc-version Retourne la version, uniquement <major>.<minor>
gcc-major-version Retourne le numéro de version majeur
gcc-minor-version Retourne le numéro de version mineur
gcc-micro-version Retourne le numéro de version micro

Règles à utiliser pour écrire un fichier ebuild

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 (pas d'espaces). Assurez-vous que votre éditeur affiche les tabulations à moins de quatre espaces. Toujours s'assurer que vous utilisez des accolades pour encadrer les variables d'environnement. Par exemple, ${P} au lieu de simplement $P.

Les longues lignes sont coupées avec des « \ », comme par exemple :

Exemple de code 2.2 : Couper une ligne dans un ebuild

./configure \
--prefix=/usr || die "configure failed"

Pour plus de détails, référez-vous à skel.ebuild (en général il se trouve dans /usr/portage).

Si vous utilisez Vim pour éditer des ebuild ou eclass, le fichier par défaut de vimrc, /etc/vim/vimrc, s'assure déjà de l'indentation correcte et des configurations concernant le type de fichier des ebuild et eclass existent. Pour de meilleurs résultats, comme par exemple avoir une coloration syntaxique spécifique aux mots-clefs des ebuilds, installez app-vim/gentoo-syntax.

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 « gentoo-syntax » qui peuvent être téléchargés à partir des serveurs mirroirs de Gentoo.

Exemple de code 2.3 : 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

Si vous utilisez Emacs, vous pouvez installer par la commande emerge, le paquetage « app-emacs/gentoo-syntax » (pour GNU Emacs ou « app-xemacs/gentoo-syntax » (pour XEmacs). Ces paquetages fournissent des fonctions majeures pour Emacs pour l'indentation automatique et pour la mise en surbrillance des fichiers « ebuild » et des autres types de fichiers spécifiques au système d'exploitation Gentoo.

Si vous utilisez nano, alors vous avez de la chance ! Éditez simplement /etc/nanorc et décommentez la section liée aux ebuilds.

Les paramètres USE

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 options de compilation. Voici un exemple. Imaginons que vous soyez un fan de GNOME et vous voulez que tous les ebuilds qui ont gnome comme option de compilation le supporte effectivement. Alors, vous ajouteriez gnome à votre variable USE dans /etc/make.conf 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 /etc/make.conf et assurez-vous que gnome n'est pas présent dans la variable USE. Gentoo a un nombre important 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 USE par paquet, en éditant le fichier /etc/portage/package.use.

Note : Si vous enlevez un paramètre USE (par exemple, enlever gnome de USE), cela ne fera que préciser à Portage de ne pas activer le support optionnel de GNOME dans vos paquets. Cela dit, si vous installez un ebuild qui nécessite 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 emerge --pretend (ou mieux emerge --ask) avant de procéder à l'installation effective. De cette manière, vous saurez exactement ce qui sera installé par emerge.

Dans vos propres ebuilds, vous pouvez vérifier si une variable USE est présent en utilisant la commande use <variable>. Elle s'utilise comme suit  :

Exemple de code 2.4 : Vérifier qu'un paramètre USE est défini

if use X; then
  # Commands specific to X...
fi

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 param? (macategorie/monpaquet) dans la variable DEPEND de votre ebuild. Dans cet exemple, macategorie/monpaquet ne seront requis que si param est présent dans USE. Il est également possible de spécifier une dépendance qui devrait être honorée si un certain paramètre USE est présent et quelle dépendance devrait être utilisée si il n'est pas présent. Cela se fait ainsi : param? ( macat/monpaquet ) et !param? ( autrecat/autrepaquet ). Dans ce cas, si param n'est pas présent, autrecat/autrepaquet sera utilisé à la place de macat/monpaquet. Assurez-vous que vos ebuilds utilisent cette syntaxe et non pas une condition BASH. Les conditions BASH interfèrent avec le cache des dépendances de Portage et l'utilisation de celles-ci casserait votre ebuild.

Voici un point important sur l'utilisation de USE. La plupart du temps, un paquet aura un script ./configure utilisé pour effectuer les diverses étapes de configuration. En général, si votre ebuild utilise ./configure, toutes les fonctionnalités optionnelles seront activées ou désactivées en passant les bons arguments à la commande ./configure. Voici le meilleur moyen de faire cela :

Exemple de code 2.5 : 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!"
}

Cette méthode produit un très bon résultat. Nous n'avons pas à nous préoccuper de savoir quelles sont les configurations par défaut pour mysql ou X (activé/désactivé), nous indiquons explicitement à econf ce que nous voulons qu'il fasse, d'après les paramètres USE. En plus, vous obtenez un code propre et facile à lire.

Parfois, des options peuvent être conflictuelles. Retourner une erreur dans ce cas n'est pas une solution. Il vaut mieux choisir la meilleure option et ignorer l'autre. Pour cela, consultez les responsables du paquet en amont pour voir ce qu'ils recommandent, voyez quelle solution offre le plus de fonctionnalités ou lancez une pièce et choisissez pile ou face. Par exemple, l'ebuild msmtp peut utiliser SSL avec GnuTLS ou avec OpenSSL, ou pas de SSL du tout. GnuTLS est préféré, car il offre plus beaucoup plus de fonctionnalités que OpenSSL.

Exemple de code 2.6 : Choisir parmi des options conflictuelles

src_compile() {
    local myconf
 
    if use gnutls ; then
        myconf="${myconf} --enable-ssl --with-ssl=gnutls"
    elif use ssl ; then
        myconf="${myconf} --enable-ssl --with-ssl=openssl"
    else
        myconf="${myconf} --disable-ssl"
    fi
 
    econf \
        # Other stuff
        ${myconf} \
        || die "configure failed"
 
    emake || die "make failed"
}

Pour avoir une table des paramètres USE mise à jour en permanence, voyez ce lien.

1.c. Emplacements des systèmes de fichiers

Introduction à FHS

Les standards de systèmes de fichiers utilisés dans Gentoo Linux suivent de près le système FHS (pour File system Hierarchy Standard, 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 pathname.

Note : La hiérarchie /opt est donnée dans la section 3.12 du FHS. La section 4.4 s'occupe de ce qui concerne le répertoire /usr/X11R6. 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.

Comment placer vos paquets dans le système de fichiers

Normalement, si le paquet utilise autoconf et automake, les destinations par défaut de l'installation du paquet sont correctes, à quelques exceptions près :

  • Si vous installez un programme dans /bin, /sbin, /usr/bin ou /usr/sbin, alors les pages de manuel correspondant à votre programme devraient être installées dans le répertoire /usr/share/man. Cela peut se faire en général en le spécifiant dans l'ebuild avec la ligne ./configure --mandir=/usr/share/man.
  • Les fichiers info GNU doivent toujours être installés dans /usr/share/info, même si les fichiers info sont à propos de programmes et outils spécifiques à X11, GNOME ou KDE. Faites bien attention. /usr/share/info est l'unique emplacement officiel pour les fichiers info GNU. Dans la mesure où plusieurs scripts ./configure installent pas défaut les fichiers info GNU dans /usr/info, il est souvent nécessaire de faire un appel à ./configure avec pour argument --infodir=/usr/share/info.
  • Les fichiers de documentation sont installés dans /usr/share/doc 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 /usr/share pour leurs propres besoins.
  • Les programmes et bibliothèques spécifiques à X11 doivent toujours être installés dans /usr et non directement dans /usr/X11R6. Nous réservons la hiérarchie /usr/X11R6 pour le système X, version 11, sortie R6 en personne. D'autres distributions feront probablement une interprétation différente du FHS concernant cette hiérarchie.
  • Les programmes GNOME et KDE, de la même manière, doivent être installés dans /usr.

Important : Certaines distributions choisissent d'installer GNOME et KDE dans /opt. 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 /usr.

En général, vos ebuilds doivent installer leurs fichiers dans l'arborescence /usr. Quelques 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 /usr, ce qui empêche les ambiguïtés et évite une complexité inutile pour les auteurs d'ebuilds. L'emplacement dans lequel doivent être installés les fichiers d'un programme ne doit pas dépendre de la présence ou non de paramètres USE. Du coup, les ebuilds dans l'arbre de Portage s'installent presque toujours dans la hiérarchie /usr exclusivement.

Note : Le répertoire /opt 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 /etc/env.d/foo. Cela a pour objectif d'inclure dans l'environnement les répertoires et les variables additionnelles nécessaires. Pour plus d'informations sur /etc/env.d, lisez le chapitre ce Manuel Gentoo.

1.d. Les scripts et utilitaires de Portage

Scripts publiques

Des scripts permettent à un administrateur système d'installer ou supprimer les paquets et de maintenir à jour la base de données des paquets.

ebuild 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 : ebuild chemin/vers/paquet.ebuild commande. Les commandes disponibles sont :

Commande Description Fonction ebuild associée
setup* Effectue toutes les commandes nécessaires avant qu'un ebuild ne commence son travail effectif pkg_setup
depend Affiche les dépendances requises à la construction du paquet Non disponible
merge* Désarchive, compile, installe et fusionne le paquet dans le système de fichiers Non disponible
qmerge* 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 Non disponible
unpack* Désarchive une archive source dans le répertoire de travail src_unpack
compile* Compile le paquet src_compile
rpm Crée un RPM à partir du paquet Non disponible
package Crée un paquet Gentoo tbz2 Non disponible
prerm* Exécute une étape de pré-suppression de paquet pkg_prerm
postrm* Exécute une étape de post-suppression de paquet pkg_postrm
preinst* Exécute une étape de pré-installation du paquet pkg_preinst
postinst* Exécute une étape de post-installation du paquet pkg_postinst
config Met en place une configuration par défaut, une fois que le paquet a été fusionné pkg_config
touch* Met à jour l'attribut mtimes pour chaque archive source dans un paquet Non disponible
clean* Nettoie le répertoire de travail pour un paquet Non disponible
fetch* Récupère les archives sources du paquet Non disponible
manifest* Crée un fichier Manifest pour un paquet Non disponible
test* Exécute la routine de test automatique du paquet src_test
install* Installe le paquet dans le répertoire image src_install
unmerge Désinstalle le paquet du système de fichiers Non disponible

Note : Les commandes avec un astérisque (*) ne sont en généralement utilisées que par le développeur.

emerge 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 emerge --help pour en avoir la liste.

env-update met à jour les fichiers de configuration (entre autres mais pas seulement : /etc/ld.so.conf et /etc/profile.env) pour inclure les changements effectués par les paquets installés.

Scripts et commandes privés

Vous pouvez utiliser certains scripts dans vos fichiers ebuilds pour réaliser des tâches communes.

Si vous voulez un aperçu, jetez un œil aux scripts eux-mêmes dans /usr/lib/portage/bin.

Commande Valeur par défaut Description Exemple
diropts -m0755 Fixe les options utilisées lors de l'utilisation de dodir diropts -m0750
dobin N/A Installe les binaires spécifiés dans DESTTREE/bin dobin wmacpi
docinto "" Fixe le sous-répertoire relatif utilisé par dodoc (DOCDESTREE) docinto exemples
dodir N/A Crée un répertoire, en utilisant de manière transparente ${D} dodir /usr/lib/nouveaupaquet
dodoc N/A Installe les fichiers spécifiés dans le répertoire de documentation du paquet en question (/usr/share/doc/${PF}/DOCDESTTREE) (voir docinto) dodoc README *.txt
doexe N/A Installe les fichiers spécifiés avec le mode EXEOPTIONS (cf. exeopts) dans PATH défini par EXEINTO (cf. exeinto). doexe ${FILESDIR}/quake3
dohard N/A Crée un lien dur, en utilisant de manière transparente ${D} dohard ls /bin/dir
dohtml N/A Installe les fichiers spécifiés et les répertoires dans /usr/share/doc/${PF}/html dohtml -r doc/html/*
doinfo N/A Installe les fichiers spécifiés dans /usr/share/info, puis les compresse avec gzip doinfo doc/*.info
doins N/A Installe les fichiers spécifiés avec le mode INSOPTIONS (voir insopts) dans INSDESTTREE (voir insinto) doins *.png icone.xpm
dolib N/A Installe les bilbiothèques spécifiées dans DESTTREE/lib avec le mode 0644 dolib *.a *.so
dolib.a N/A Installe les bibliothèques spécifées dans DESTTREE/lib avec le mode 0644 dolib.a *.a
dolib.so N/A Installe les bibliothèques spécifées dans DESTTREE/lib avec le mode 0755 dolib.so *.so
doman N/A Installe les fichiers spécifiés dans /usr/share/man/manX, selont le suffixe du fichier (file.1 ira dans man1) doman *.1 *.5
dosbin N/A Installe les fichiers dans DESTTREE/sbin, en s'assurant qu'ils sont exécutables dosbin ksymoops
dosym N/A Crée un lien symbolique, en utilisant ${D} de manière transparente dosym gzip /bin/zcat
emake N/A Exécute make avec MAKEOPTS. Certains paquets ne peuvent pas être faits en parallèle. Utilisez emake -j1 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 EXTRA_EMAKE pour passer des paramètres supplémentaires à emake. emake
exeinto / Fixe la racine (EXEDESTTREE) pour la commande doexe exeinto /usr/lib/${PN}
exeopts -m0755 Fixe les options utilisées lors de l'utilisation de doexe exeopts -m1770
fowners N/A Applique l'appartenance spécifique d'un fichier à un utilisateur, en utilisant la commande chown et en utilisant ${D} de manière transparente fowners root:root /sbin/fonctions.sh
fperms N/A Applique les permissions spécifiques à un fichier spécifique via la commande chmod, en utilisant ${D} de manière transparente fperms 700 /var/consoles
insinto /usr Fixe la racine (INSDESTTREE) pour la commande doins insinto /usr/include
insopts -m0644 Fixe les options utilisées lors du lancement de doins insopts -m0444
into /usr Fixe le préfixe de la cible (DESTTREE) pour toutes les commandes 'do' (comme dobin, dolib, dolib.a, dolib.so, domo, dosbin) into /
libopts -m0644 Fixe les options utilisées lors de l'exécution de dolib libopts -m0555
newbin N/A Couche supplémentaire à dobin qui installe le binaire spécifié et le renomme de manière transparente au second argument. newbin ${FILESDIR}/vmware.sh vmware
newdoc N/A Surcouche de dodoc qui installe le fichier spécifié et le renomme de manière transparente au second argument newdoc README README.opengl
newexe N/A Surcouche de doexe qui installe le fichier spécifié et le renomme de manière transparente au second argument newexe ${FILESDIR}/xinetd.rc xinetd
newins N/A Surcouche de doins qui installe le fichier spécifié et le renomme de manière transparente au second argument newins ntp.conf.example ntp.conf
newman N/A Surcouche de doman qui installe le fichier spécifié et le renomme de manière transparente au second argument newman xboing.man xboing.6
newsbin N/A Surcouche de dosbin qui installe le fichier spécifié et le renomme de manière transparente au second argument newsbin strings strings-static
prepall N/A Exécute prepallman, prepallinfo et prepallstrip. Cette fonction s'assure de plus que toutes les bibliothèques dans /opt/*/lib, /lib, /usr/lib et /usr/X11R6/lib sont exécutables. Enfin, déplace et isole les macros aclocal dans /usr/share/aclocal prepall
prepalldocs N/A Le fonctionnement de Portage a évolué et les nouveaux ebuilds ne doivent plus utiliser cette fonction. prepalldocs
prepallinfo N/A Archive de manière récursive avec gzip tous les fichiers info dans /usr/share/info prepallinfo
prepallman N/A Archive de manière récursive avec gzip toutes les pages man dans /opt/*/man/*, /usr/share/man/*, /usr/local/man/*, /usr/X11R6/share/man/* et s'occupe de manière transparente des liens symboliques prepallman

1.e. Les dépendances des paquets

Pourquoi les dépendances sont importantes

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.

Dans les ebuilds officiels, toutes les dépendances ont été spécifiées de telle manière que si vous exécutez emerge net-www/mozilla/mozilla-1.0, 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.

Portage va même jusqu'à distinguer les dépendances dues à la compilation et celles dues 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.

Comment préciser les dépendances dans vos ebuild

La variable DEPEND dans votre foo-x.y.z.ebuild indique à Portage les paquets qui sont nécessaires à la construction de foo. La variable RDEPEND indique à Portage les paquets nécessaires au lancement du paquet. La variable RDEPEND doit être explicitement renseignée même si son contenu est le même que la variable DEPEND car prochainement, cette variable dont elle correspond par défaut « DEPEND » ne sera plus utilisé par le système de gestion des paquetages Portage de Gentoo.

Exemple de code 5.1 : Exemple de dépendances

DEPEND="virtual/opengl
        dev-libs/libxml2"
RDEPEND="${DEPEND}"

Cela indique à Portage de construire foo-x.y.z, les paquets virtual/opengl (plus de précisions sur les virtuals seront données plus tard) et dev-libs/libxml2 étant nécessaires à la construction. Il ne précise pas la version d'opengl ou de libxml2 dont vous avez besoin, ce qui signifie que n'importe laquelle ira très bien.

La mention de n'importe laquelle fait évidemment un peu peur et ne fonctionnera pas en général. En revanche, pour des bibliothèques centrales qui font tout pour avoir des binaires toujours compatibles, cela fonctionnera. Pour d'autres bibliothèques, on peut évidemment préciser la version des dépendances.

Exemple de code 5.2 : Exemple avec les versions

>=sys-apps/bar-1.2
 =sys-apps/baz-1.0

>= 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 nommer des fichiers ebuild.

Voici d'autres méthodes pour spécifier la version des dépendances :

Exemple de code 5.3 : Spécifier la version des dépendances

~sys-apps/qux-1.0
=sys-apps/foo-1.2*
!sys-libs/gdbm

~sys-apps/qux-1.0 va sélectionner la révision la plus récente de qux-1.0 dans Portage.

=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. Veuillez noter que la version foo-1.22.3 correpond aussi et pourrait très bien provoquer des problèmes dans certains cas.

!sys-libs/gdbm vous empêchera d'installer ce paquet tant que gdbm sera déjà installé.

À noter

De nombreux problèmes peuvent survenir à cause des variables DEPEND et RDEPEND. Les conseils suivants devraient vous aider à éviter ces problèmes :

  • Toujours indiquer la catégorie.
    Par exemple, utilisez >=x11-libs/gtk+-2 et pas >=gtk+-2 ;
  • Ne pas utiliser d'astérisque (*) pour les dépendances >=.
    Par exemple, utilisez >=x11-libs/gtk+-2 et pas >=x11-libs/gtk+-2* ;
  • Ne pas créer de dépendance sur un meta-paquet.
    Ne faites pas dépendre vos ebuilds de gnome-base/gnome, mais utilisez la bibliothèque spécifique ;
  • Une seule dépendance par ligne.
    Ne mettez pas plusieurs dépendances sur la même ligne, car elles difficiles à lire ;
  • GTK: toujours utiliser =x11-libs/gtk+-1.2* pour des applications GTK+1.

De plus, il est important de vérifier que toutes les dépendances sont mentionnées :

  • Regardez dans configure.in ou configure.ac.
    Cherchez y des tests sur la présence de paquets tels que pkg-config ou des fonctions AM_* qui testent des versions spécifiques ;
  • Regardez dans les fichiers .spec.
    Ces fichiers donnent de bonnes indications quant aux dépendances, mais ne les considérez pas commme complets ;
  • Consultez le site de l'application ou de la bibliothèque.
    Vérifiez les dépendances mentionnées sur les sites concernés ;
  • Lisez le fichiers README et INSTALL du paquet.
    Ils contiennent souvent des indications précieuses ;
  • N'oubliez pas les dépendances non-relatives au programme même, par exemple pkg-config, la génération de la documentation, etc.
    Généralement, la compilation nécessite des outils tels que intltool, libtool, pkg-config, doxygen, scrollkeeper, gtk-doc, etc. Vérifiez que ces dépendances sont indiquées.

Pour les derniers détails sur les éléments DEPEND, lisez la section 5 de la page man sur les ebuilds : man 5 ebuild.

1.f. Tester et déployer

ChangeLog

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 skel.ChangeLog contient un exemple de ChangeLog que vous pouvez utiliser comme base.

L'objectif du ChangeLog est de documenter ce qui a été fait, pourquoi cela a été fait et par qui. Cela permet à la fois aux développeurs et aux utilisateurs de garder une trace des changements effectués de manière simple.

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.

Sauvegarder vos propres ebuilds localement

Afin de pouvoir tester vos ebuilds et de permettre à Portage de les utiliser, vous devez les placer dans un répertoire connu. Portage utilisera la variable PORTDIR_OVERLAY que vous pouvez définir dans /etc/make.conf. Vous devriez fixer cette variable à votre répertoire local de travail (par exemple, /usr/local/portage).

Dans ce répertoire, vous devez avoir la même structure (et les mêmes catégories) que dans /usr/portage.

En utilisant PORTDIR_OVERLAY, vos ebuilds restent sur votre système, même après un emerge sync et ils restent connus de Portage.

Tester le paquet

Prenez le temps de penser à la façon de tester votre paquet. Parfois, les développeurs ont intégré une routine make check qui permet de tester les fonctionnalités de base du paquet. Dans ce cas, la commande FEATURES=test ebuild foo-x.y.z.ebuild test l'exécutera. Si cela ne fonctionne pas, essayez de résoudre le problème et proposez votre solution aux développeurs du paquet.

Dans le cas contraire, pensez à ajouter une routine src_test à votre ebuild. Elle sera exécutée avant la routine src_install et permet de vérifier que le programme fonctionne sur toutes les architectures. Chaque responsable d'une architecture appréciera cette fonction, car elle leur évite de devoir connaître le paquet en question.

N'oubliez pas les spécifications des ebuilds. La routine src_test ne doit pas être interactive. Si elle dépend d'autres paquets, utilisez l'option USE test pour indiquer qu'il y a des dépendances à la compilation. De plus, remarquez qu'une routine src_test n'est pas recommandée pour des applications graphiques X, car l'utilisateur qui exécute portage ne peut généralement pas lancer ce type d'application.

Outils de tests utiles

Vous disposez de quelques outils pratiques pour vous aider à écrire et maintenir vos ebuilds.

Outil Paquet Description
repoman sys-apps/portage 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 essaie de s'assurer que les fichiers ajoutés dans le cvs ne vont pas casser l'arborescence de Portage.
ccache dev-util/ccache Outil qui garde les fichiers pré-compilés, pour pouvoir rendre la compilation plus rapide. Assurez-vous d'ajouter ccache dans votre variable FEATURES dans le fichier /etc/make.conf
sandboxshell app-shells/sandboxshell 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.
echangelog app-portage/gentoolkit-dev Permet de créer un nouveau ChangeLog ou d'ajouter une entrée dans un ChangeLog déjà existant.

[ << ] [ < ] [ Sommaire ] [ > ] [ >> ]


Imprimer

Voir tout

Dernière mise à jour le 1er novembre 2007

Résumé : Cette section décrit le système Portage de Gentoo, comment créer des nouveaux paquets pour Gentoo. Il doit également être vu par les développeurs comme un standard. Ce document est en constante évolution et est mis à jour et modifié régulièrement. Vous devez utiliser ce document comme un complément aux pages man proposées par Portage (et tout particulièrement ebuild(5)) et aux politiques de développement de Gentoo.

Donny Davies
HOWTO Ebuilds - Auteur

Peter Gavin
Auteur

Karl Trygve Kalleberg
Auteur

Mike Frysinger
Auteur

Daniel Robbins
Auteur/Relecteur

John P. Davis
Auteur/Relecteur

Jorge Paulo
Relecteur

Sven Vermeulen
Relecteur

Zack Gilburd
Relecteur

Benny Chuang
Relecteur

Erwin
Relecteur

Dan Armak
HOWTO Eclass - Autheur

Alastair Tse
Erreurs Classiques pour les ebuilds - Auteur

Paul De Vrieze
Documentation Metadata - Auteur

Owen Stampflee
Politique générale concernant les ebuilds - Auteur

Seemant Kulleen
Relecteur

Jon Portnoy
Relecteur

Carl Anderson
Relecteur

Ciaran McCreesh
Correcteur

Nicholas D. Wolfwood
Correcteur

Marius Mauch
Correcteur

Daniel Black
Correcteur

Tim Yamin
Auteur/Relecteur

Wernfried Haas
Correcteur

Shyam Mani
Relecteur

L'équipe relationnelle des développeurs Gentoo
Relecteurs

Clément Varaldi
Traducteur

Xavier Neys
Traducteur

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.