Attachment #208363 for bug #290640

View | Details | Raw Unified | Return to bug 290640
Collapse All | Expand All





<sections>

<version>1.0.4</version>
<date>2007-11-01</date>

<section>
<title>L'arbre de Portage</title>

<path>util-linux-2.11y.ebuild</path>. C'est dû au fait que <e>tous les ebuilds
pour un paquet particulier</e> (quelle que soit la version) partagent le même
répertoire <path>ma_categorie/mon_paquet</path> dans
<path>/usr/portage</path>, à moins que vous avez des surcouches
«&nbsp;overlays&nbsp;» installées.
</p>

</body>

solutionpour 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.mandriva.com/cgi-bin/viewvc.cgi/SPECS/">Mandriva</uri> ou
<uri link="http://www.debian.org/distrib/packages">Debian</uri> ou
<uri link="http://cvs.fedora.redhat.com/">Fedora</uri> pour avoir de bons
exemples.


<p>
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
<uri link="http://devmanual.gentoo.org/ebuild-writing/variables/index.html">
le guide de développement</uri>.
</p>

<ul>
<li>
  READ&nbsp;: les variables que vous pouvez utiliser, mais qui ne <e>sont
  jamais modifées</e>&nbsp;;
</li>
<li>
  MUST&nbsp;: les variables que vous devez <e>toujours déclarer</e>&nbsp;;
</li>
<li>
  OPT&nbsp;: les variables que vous devriez définir.
</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 liens URL, juste le nom de fichier.
  </ti>
</tr>

<tr>
  <ti><c>DISTDIR</c></ti>
  <ti>READ</ti>
  <ti>
    Contient le nom du répertoire <path>distfiles</path> où sont mis tous
    les fichiers récupérés pour un paquet. C'est en général
    <path>/usr/portage/distfiles</path>.
  </ti>
</tr>

<tr>
  <ti><c>FILESDIR</c></ti>
  <ti>READ</ti>
  <ti>
    Contient le chemin vers le sous-répertoire <path>files/</path> dans
    l'emplacement spécifique du paquet dans l'arbre de Portage.  Ne modifiez
    pas cette variable.
  </ti>
</tr>

<tr>
  <ti><c>WORKDIR</c></ti>
  <ti>READ</ti>
  <ti>
    Base de la racine de travail pour un ebuild. Rien ne doit être construit
    hors de ce répertoire.
  </ti>
</tr>

<tr>
  <ti><c>S</c></ti>
  <ti>OPT</ti>
  <ti>
    Le répertoire source pour votre paquet, en général <c>${WORKDIR}/${P}</c>.
    Portage va prendre cette valeur par défaut donc vous n'avez probablement pas
    besoin de l'initialiser.
  </ti>
</tr>

<tr>
  <ti><c>T</c></ti>
  <ti>READ</ti>
  <ti>
    Le répertoire temporaire pour votre paquet. Il est utilisé lors de
    l'exécution de l'ebuild à la manière du répertoire <path>/tmp</path>.
  </ti>
</tr>

<tr>
  <ti><c>D</c></ti>
  <ti>READ</ti>
  <ti>
    Le répertoire racine où le paquet devra être installé. Considérez-le comme
    une racine d'arborescence (<path>/</path>) virtuelle.
  </ti>
</tr>

<tr>
  <ti><c>SLOT</c></ti>
  <ti>MUST</ti>
  <ti>
    Portage manipule souvent plusieurs versions d'un même programme installées.
    Par exemple vous pouvez avoir GCC&nbsp;2.95 et GCC&nbsp;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&nbsp;2.95 la valeur <c>2</c> alors que nous aurions utilisé la valeur
    <c>3</c> pour le <c>SLOT</c> de GCC&nbsp;3.2.<br/>
    <b>Note</b>&nbsp;: 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 «&nbsp;SLOTable&nbsp;»).
  </ti>
</tr>

<tr>
  <ti><c>LICENSE</c></ti>
  <ti>MUST</ti>
  <ti>
    Cette variable spécifie la licence du programme, par exemple GPL-2, BSD,
    etc. Ce champ doit être initialisé à une valeur de licence valide (qui peut
    être n'importe quelle licence présente dans le répertoire
    <path>/usr/portage/license/</path>). Si la licence n'y est pas encore
    répertoriée, elle doit être ajoutée avant d'ajouter l'ebuild à l'arbre de
    Portage.
  </ti>
</tr>

<tr>
  <ti><c>KEYWORDS</c></ti>
  <ti>MUST</ti>
  <ti>
    Cette variable remplit désormais un certain nombre de rôles. Tout d'abord,
    elle spécifie la cible de l'ebuild en matière d'architecture. Les
    mots-clefs incluent&nbsp;: <e>x86, ppc, sparc, mips, alpha, arm, hppa,
    amd64, ia64</e> La liste des architectures est dans le fichier
    <path>profiles/arch.list</path>. Évidemment, vous utiliserez ceci pour
    indiquer l'architecture de la machine cible. Portage n'autorisera pas une
    machine x86 à construire autre chose que des ebuilds dont le mot-clef x86
    est spécifié dans la variable <c>KEYWORDS</c>. Les paquets qui ne
    supportent pas une architecture nativement sont automatiquement masqués par
    Portage. Si le paramètre <c>KEYWORDS</c> est précédé d'un <e>~</e>, alors
    cela indique que l'ebuild fonctionne, mais nécessite encore plusieurs tests
    dans différents environnements avant d'être placé dans un profil stable
    avec le mot-clef associé.  Si le paramètre <c>KEYWORDS</c> est précédé d'un
    <e>-</e> (tiret), alors le paquet ne fonctionne pas pour l'architecture
    concernée.  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 URL pour chaque fichier source de votre paquet séparés d'un espace.
    Vous devez essayer de ne pas utiliser le numéro de version du paquet dans
    les variables SRC_URI et S. Utilisez les variables ${PV} ou ${P}. Si l'URL
    ne correspond pas exactement ou pas du tout au nom du paquet, définissez
    une variable ${MY_P} et utilisez-la.
  </ti>
</tr>

<tr>
  <ti><c>HOMEPAGE</c></ti>
  <ti>MUST</ti>
  <ti>
    La page Internet dédiée au paquet. Si vous n'arrivez pas à trouver la page
    officielle, essayez de trouver un lien depuis le site <uri
    link="http://freshmeat.net/">freshmeat.net</uri> ou un site de traçage de
    paquets similaires. N'utilisez jamais de variables dans la description,
    uniquement du text pur.
  </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é&nbsp;!
  </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,
    lisez 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>

  <ti>
    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.
    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>


  <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>emake DESTDIR=${D} install</c>. <e>Assurez-vous que votre paquet installe
    tous ses fichiers en utilisant <c>D</c> comme racine&nbsp;!</e> Le
    répertoire initial de travail est <c>S</c>.
  </ti>

<tr>
  <ti><c>use</c></ti>
  <ti>
    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 <c>usev</c> qui affichera les options USE qui ont été
    sélectionnées.
  </ti>
</tr>


    une fois, vous pouvez donner des arguments supplémentaires à la commande
    make en les donnant directement comme paramètres à <c>einstall</c>. Notez
    que la méthode utilisée de manière préférentielle pour installer un paquet
    est d'utiliser la commande <c>emake install DESTDIR="${D}"</c> et non
    <c>einstall</c>. Cette commande n'est en fait qu'une alternative aux
    fichiers make défectueux.
  </ti>

</tr>

<tr>
  <ti><c>elog</c></ti>
  <ti>
    Informe l'utilisateur d'un événement important. L'argument passé à
    <c>elog</c> est le message qui sera donné à l'utilisateur. N'utilisez pas
    <c>elog</c> pour afficher des bannières comme
    "*************************************". Le fait même d'utiliser
    <c>elof</c> est suffisant pour attirer l'attention de l'utilisateur. Le
    message est aussi sauvegardé dans un fichier de traçage («&nbsp;log&nbsp;»)
    en utilisant le système «&nbsp;ELOG&nbsp;» de Portage.
  </ti>
</tr>
<tr>
  <ti><c>einfo</c></ti>
  <ti>
    Affiche des informations moins importantes qui ne seront pas sauvegardés
    dans un fichier de traçage («&nbsp;log&nbsp;»).
  </ti>
</tr>
</table>

    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&nbsp;: <c>$2</c> contient un UID. Mettre -1 pour que
    l'UID prenne le prochain ID disponible. <c>$3</c> contient un shell. Mettre
    -1 pour que prendre le shell par défaut. <c>$4</c> contient le répertoire
    utilisateur avec <path>/dev/null</path> comme répertoire par défaut.
    <c>$5</c> contient tous les groupes auquel l'utilisateur doit être ajouté,
    vide par défaut et <c>$6</c> contient les éventuels paramètres à passer à la
    commande <c>useradd</c> lors de la création de l'utilisateur.
  </ti>
</tr>


<tr>
  <ti><c>replace-cpu-flags</c></ti>
  <ti>
    Cette fonction nécessite deux arguments. Il remplace une valeur de type
    mtune/march/mcpu par une autre (Par exemple, «&nbsp;replace-cpu-flags 'i686' 'i586'&nbsp;»
    remplacera -mtune/-march/-mcpu=i686 par -mtune/-march/-mcpu=i586).
  </ti>
</tr>


</tr>
</table>

<p><b>Les fonctions d'assistance fournies par toolchain-funs.eclass</b></p>

<p>
Vous pouvez aussi utiliser les fonctions suivantes fournies par l'eclass
"toolchain-funcs". Vous devez vous assurer que <c>inherit toolchain-funcs</c>

<p>
Sur les systèmes non Gentoo, vous pouvez obtenir des résultats similaires en
utilisant les lignes suivantes dans votre vimrc, ou mieux en installant les
scripts «&nbsp;gentoo-syntax&nbsp;» qui peuvent être téléchargés à partir des
serveurs mirroirs de Gentoo.
</p>

<pre caption="Configurer vimrc pour éditer des ebuilds">

</pre>

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

<pre caption="Configurer emacsrc pour éditer les ebuilds">
(defun ebuild-mode ()
  (shell-script-mode)
  (sh-set-shell "bash")
  (make-local-variable 'tab-width)
  (setq tab-width 4))
(setq auto-mode-alist (cons '("\\.ebuild$" . ebuild-mode) auto-mode-alist))
(setq auto-mode-alist (cons '("\\.eclass$" . ebuild-mode) auto-mode-alist))
</pre>

<p>
Si vous utilisez nano, alors vous avez de la chance&nbsp;! Éditez simplement
<path>/etc/nanorc</path> et décommentez la section liée aux ebuilds.

</note>

<p>
Dans vos propres ebuilds, vous pouvez vérifier si une variable USE est présent
en utilisant la commande <c>use &lt;variable&gt;</c>. Elle s'utilise comme suit
&nbsp;:
<c>USE</c> de l'utilisateur. Vous pouvez l'utiliser comme suit&nbsp;:
</p>

<pre caption="Vérifier qu'un paramètre USE est défini">

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 <c>msmtp</c> 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.
</p>

<pre caption="Choisir parmi des options conflictuelles">

  <ti>Non disponible</ti>
</tr>
<tr>
  <ti><c>manifest</c>*</ti>
  <ti>Crée un fichier Manifest pour un paquet</ti>
  <ti>Non disponible</ti>
</tr>
<tr>

  <ti><path>""</path></ti>
  <ti>
    Fixe le sous-répertoire relatif utilisé par <c>dodoc</c>
    (DOCDESTREE)
  </ti>
  <ti><c>docinto exemples</c></ti>
</tr>

  <ti><c>doexe</c></ti>
  <ti>N/A</ti>
  <ti>
    Installe les fichiers spécifiés avec le mode <e>EXEOPTIONS</e> (cf.
    <c>exeopts</c>) dans <path>PATH</path> défini par <e>EXEINTO</e> (cf.
    <c>exeinto</c>).
  </ti>
  <ti><c>doexe ${FILESDIR}/quake3</c></ti>
</tr>

  <ti><c>prepalldocs</c></ti>
  <ti>N/A</ti>
  <ti>
     Le fonctionnement de Portage a évolué et les nouveaux ebuilds ne doivent
     plus utiliser cette fonction.
     des liens symboliques
  </ti>
  <ti><c>prepalldocs</c></ti>
</tr>

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

<pre caption="Exemple de dépendances">
DEPEND="virtual/opengl
        dev-libs/libxml2"
RDEPEND="${DEPEND}"
</pre>

<p>
Cela indique à Portage de construire <path>foo-x.y.z</path>, les paquets
<path>virtual/opengl</path> (plus de précisions sur les virtuals seront données
plus tard) et <path>dev-libs/libxml2</path> é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 <e>n'importe laquelle</e> ira très bien.
</p>

<p>
La mention de <e>n'importe laquelle</e> 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.
</p>

=sys-apps/foo-1.2* va selectionner le membre le plus récent de la série 1.2,
mais ignorera la 1.3 et les versions plus récentes/vieilles. Ainsi foo-1.2.3 et
foo-1.2.0 sont tous les deux valides, mais foo-1.3.3, foo-1.3.0 et foo-1.1.0 ne
le sont pas. Veuillez noter que la version foo-1.22.3 correpond aussi et
pourrait très bien provoquer des problèmes dans certains cas.
</p>

<p>

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

<p>

    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.
  </ti>
</tr>


  <ti>
    Ouvre un shell qui crée un environnement «&nbsp;bac à sable&nbsp;». Très
    utile pour entrer dans le même environnement que celui dans lequel Portage
    construit les paquets, et y appliquer manuellement des corrections.
  </ti>
</tr>


  <ti>app-portage/gentoolkit-dev</ti>
  <ti>
    Permet de créer un nouveau ChangeLog ou d'ajouter une entrée dans un
    ChangeLog déjà existant.
  </ti>
</tr>
</table>

Return to bug 290640