Attachment 78174 Details for Bug 120435 – Updated XML file

Updated XML file

porting-modular-x-howto.xml (text/plain), 10.87 KB, created by Bertrand on 2006-01-26 08:40:26 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Bertrand

Created: 2006-01-26 08:40:26 UTC

Size: 10.87 KB

patch

obsolete

><?xml version="1.0" encoding="UTF-8"?>
>
>
><!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
>
><guide link="/proj/fr/desktop/x/x11/porting-modular-x-howto.xml" lang="fr">
><title>Guide de portage vers X modulaire</title>
>
><author title="Auteur">
>  <mail link="spyderous@gentoo.org">Donnie Berkholz</mail>
></author>
><author title="Traducteur">
>  <mail link="koppatroopa@yahoo.fr">Bertrand Coppa</mail>
></author>
>
><abstract>
>Ce guide vous explique comment porter les paquets pour qu'ils utilisent la
>nouvelle version modulaire de X.Org.
></abstract>
>
>
>
><license/>
>
><version>1.4</version>
><date>2006-01-03</date>
>
><chapter>
><title>Environnement</title>
>
><section>
><title>Introduction</title>
><body>
>
><p>
>Vous vous demandez surement pourquoi changer un simple et unique paquet
>xorg-x11 en environ 300 paquets sÃ©parÃ©s. Cela est justifiÃ©.  Ce n'est pas
>Gentoo qui a fait ce choix indÃ©pendament du projet X.Org&nbsp;; ce sont leurs
>dÃ©veloppeurs qui ont dÃ©cidÃ© de sÃ©parer tous ces paquets, et nous ne faisons que
>suivre.
></p>
>
><p>
>Vous pouvez lire les dÃ©tails Ã  ce sujet dans le <uri
>link="modular-x-howto.xml#doc_chap1_sect1"> Guide de migration vers X.Org
>modulaire</uri>.
></p>
>
></body>
></section>
></chapter>
>
><chapter>
><title>ContrÃ´le des dÃ©pendances</title>
><section>
><body>
>
><p>
>Nous voulons Ã©numerer les dÃ©pendances aussi finement que possible afin que les
>les gens n'aient pas plein de paquets inutiles (p.ex. XPrint) qui traÃ®nent sur
>leur systÃ¨me. On veut donc dÃ©pendre directement des paquets qui contiennent les
>bibliothÃ¨ques et les fichiers d'en-tÃªte dont on a besoin plutÃ´t que de
>n'importe quel paquet virtuel.
></p>
>
><p>
>Aussi, nous ne pouvons guarantir que les gens auront toujours des sous-paquets
>installÃ©s parce qu'ils ont un mÃ©ta-paquet installÃ© et Ã©liminer cette
>possibilitÃ© de problÃ¨me nous fera gagner beaucoup de temps qui serait perdu Ã 
>marquer les bogues Â«&nbsp;INVALID&nbsp;Â».
></p>
>
><p>
>Si je trouve un seul paquet dÃ©pendant sur n'importe quel mÃ©ta-paquet possible,
>je n'hÃ©siterai pas Ã  harasser son mainteneur jusqu'Ã  la fin des temps.
></p>
>
><p>
>La premiÃ¨re Ã©tape est d'installer X modulaire ou de trouver quelqu'un qui l'a
>installÃ©. Cela peut Ãªtre effectuÃ© dans un chroot -- il n'est pas nÃ©cessaire que
>X soit lancÃ©, il faut seulement avoir ses fichiers disponibles pour le
>contrÃ´le des dÃ©pendances.
></p>
>
><pre caption="Obtenir les scripts nÃ©cessaires">
>$ <i>wget http://dev.gentoo.org/~spyderous/scripts/linking_libs.sh \
>	http://dev.gentoo.org/~spyderous/scripts/included_headers.sh \
>	http://dev.gentoo.org/~betelgeuse/scripts/deputils/checkdeps.rb \
>  	http://dev.gentoo.org/~betelgeuse/scripts/deputils/pkgutil.rb</i>
></pre>
>
><impo>
><e>Ne pas</e> utiliser <c>gentoolkit-0.2.1_pre9</c>, cela donne des sorties
>invalides. Consultez <uri>https://bugs.gentoo.org/show_bug.cgi?id=111501</uri>.
></impo>
>
><p>
>Le premier script, <c>linking_libs.sh</c>, contrÃ´le un journal de compilation
>de votre paquet pour vÃ©rifier toutes les bibliothÃ¨ques dont il est fait
>rÃ©fÃ©rence et affiche les noms des paquets auxquels appartiennent ces
>bibliothÃ¨ques.
></p>
>
><p>
>Le second script, <c>included_headers.sh</c>, scanne le code source de votre
>paquet Ã  la recherche de lignes commenÃ§ant par #include et extrait les noms des
>fichiers inclus entre &lt;&gt;. Depuis le 9 septembre 2005, cela marche aussi
>pour les inclusions de type "".
></p>
><p>
>Le troisiÃ¨me script, <c>checkdeps.rb</c>, scanne les fichiers installÃ©s par un
>paquet en utilisant <c>scanelf</c>, obtenu avec pax-utils. C'est
>particuliÃ¨rement utile pour les paquets binaires ou les paquets qui cachent la
>sortie du compilateur. C'est un script Ruby, donc il nÃ©cessite dev-lang/ruby en
>plus de app-misc/pax-utils. Le quatriÃ¨me script, <c>pkgutil.rb</c>, est une
>dÃ©pendance de <c>checkdeps.rb</c>.
></p>
>
><p>
>Lancer les deux premiers scripts devrait vous donner une bonne liste de paquets
>pour RDEPEND (pour les bibliothÃ¨ques) et DEPEND (fichiers d'en-tÃªte et
>bibliothÃ¨ques). Si une bibliothÃ¨que appartenant Ã  RDEPEND n'appartient pas Ã 
>DEPEND, vous devriez vous mÃ©fier&nbsp;: cela pourrait Ãªtre une Â«&nbsp;fausse
>dÃ©pendance&nbsp;Â», i.e. une bibliothÃ¨que liÃ©e sans raison. Un exemple connu de
>dÃ©pendance de ce type est libXt&nbsp;; de nombreux paquets cherchent les
>fichiers d'en-tÃªte de libXt lorsqu'ils cherchent X.
></p>
>
><p>
>Parfois, la recherche de fichiers d'en-tÃªte relatifs de
><c>included_headers.sh</c> trouvera de mauvais fichiers, car il certains ont
>des nom identiques et, du coup, il renverra un mauvais paquet. En gÃ©nÃ©ral,
>l'erreur est assez visible, comme par exemple quand les fichiers 
>d'en-tÃªte Windows font donner app-emulation/wine comme dÃ©pendance.
></p>
>
><p>
>Si vous spÃ©cifiez l'option <c>-d</c>, il arrivera parfois qu'une bibliothÃ¨que
>ou qu'un fichier d'en-tÃªte soit notÃ© Â«&nbsp;Not found!&nbsp;Â». Cela peut
>vouloir dire que vous avez dÃ©sinstallÃ© un fichier d'en-tÃªte dont un paquet a
>besoin depuis que vous l'avez compilÃ©, ou bien que c'est un fichier optionnel
>que vous n'utilisez pas. Dans le cas d'une bibliothÃ¨que, cela peut vouloir dire
>que vous l'avez dÃ©sinstallÃ©e ou bien que c'Ã©tait seulement une bibliothÃ¨que
>statique compilÃ©e en interne qui n'a jamais Ã©tÃ© installÃ©e.
></p>
>
><p>
>Cela vaut le coup de passer le temps nÃ©cessaire pour savoir si les
>bibliothÃ¨ques ou les fichiers d'en-tÃªte non-trouvÃ©s doivent Ãªtre ajouter Ã  la
>liste des dÃ©pendances, particuliÃ¨rement dans le cas des fichiers d'en-tÃªte car
>on n'a pas besoin d'avoir ces fichiers installÃ©s pour lancer le scanner.
></p>
>
><p>
>Dans certains cas, les paquets ont besoin d'un serveur X rÃ©el quelconque.  Mais
>s'il ne le demande pas lors de l'installation, je vous encourage Ã  ne pas le
>mettre dans RDEPEND. Cela pose problÃ¨me avec les installations de X sur des
>machines sans Ã©cran, pour lesquelles les programmes tournent sur une autre
>machine et n'ont donc besoin que de bibliothÃ¨ques et de fichiers d'en-tÃªte
>locaux.
></p>
>
><p>
>Il y a dÃ©jÃ  un bon nombre de serveurs X dans l'arbre, donc si vous avez besoin
>d'un serveur X, veuillez tous les inclure. Les serveurs pour X modulaire sont
>dans xorg-server&nbsp;;il y a un serveur DirectFB (xdirectfb)&nbsp;; kdrive
>fournit des serveurs X lÃ©gers&nbsp;; et bien sÃ»r, les vieux  &lt;xorg-x11-7.
>SpÃ©cifiez les restrictions de versions pour xorg-x11 pour Ãªtre sÃ»r d'avoir un
>serveur X et pas un mÃ©ta-paquet. Dans un futur proche, je prÃ©vois que kdrive va
>devenir xserver. Si vous avez rÃ©ellement besoin d'un xserver, veuillez
>contacter un membre de l'Ã©quipe chargÃ©e de X. S'il y aun nombre suffisant de
>paquets demandant un xserver, il se peut qu'un Â«&nbsp;virtual&nbsp;Â» soit crÃ©Ã©.
></p>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Structure de dÃ©pendance</title>
><section>
><body>
>
><p>
>Sur le fait d'ajouter les dÃ©pendances -- on veut une structure comme
>celle-ci&nbsp;:
></p>
>
><pre caption="Structures RDEPEND/DEPEND">
>RDEPEND="|| ( ( x11-libs/libXfoo
>      x11-libs/libXbar
>      blah? ( x11-libs/libXblah )
>      tout ce qui s'affiche d'autre lors du test de bibliothÃ¨que
>    )
>    virtual/x11
>  )
>
>DEPEND="${RDEPEND}
>  || ( ( x11-proto/fooproto
>      blah? ( x11-proto/blahproto )
>      tout ce qui est affichÃ© par les deux scripts
>    )
>    virtual/x11
>  )
></pre>
>
><impo>
>Certains rÃ©sultats fournis par les scripts <e>seront</e> redondants. Si le
>RDEPEND d'une bibliothÃ¨que en inclut une autre, il n'est pas nÃ©cessaire de les
>mettre les deux en dÃ©pendances. Si le DEPEND d'une bibliothÃ¨que contient un
>prototype, il <e>faut</e> le mettre dans la liste des dÃ©pendances du paquet.
>Les candidates prÃ©visibles pour les bibliothÃ¨ques prÃ©sentes dans beaucoup
>d'autres sont <c>libXaw</c>, <c>libXmu</c>, <c>libXpm</c>, <c>libXcursor</c>,
><c>libXt</c>. Faites simplement un <c>emerge -ep $library | grep lib[SIX]</c>.
>N'oubliez pas non plus que d'autres paquets comme <c>gtk+</c> ont Ã©tÃ© portÃ©s
>pour les dÃ©pendances modulaires, donc ils peuvent fournir les bibliothÃ¨ques
>nÃ©cessaires.
></impo>
>
><note>
>Deux options distinctes de la variable USE installeront X, mais l'une n'est pas
>dÃ©pendante de l'autre. Dans ce cas lÃ , il faut soit dupliquer la section de
>dÃ©pendance vers X, soit la dÃ©finir ailleurs et l'inclure en tant que
>${X_DEPEND}. Si elle est dÃ©finie ailleurs, n'oubliez pas d'inclure aussi les
>portions spÃ©cifiques Ã  chaque option USE.
></note>
>
><p>
>Le but ici est de faire du nouveau X modulaire l'option par dÃ©faut, mais de
>permettre aux gens de satisfaire les dÃ©pendances avec l'ancien paquet
>monolithique xorg-x11. Nous abandonnons complÃ¨tement virtual/x11 afin
>d'encourager l'Ã©numÃ©ration des dÃ©pendances rÃ©elles.
></p>
>
><p>
>Pour la premiÃ¨re action sur l'arbre, l'effort de portage se focalise uniquement
>sur les ebuilds les plus rÃ©cents disponibles en ~arch, et tout ce qui est 
>encore plus rÃ©cent (KEYWORDS=-* ou package.mask). Les mainteneurs de paquets
>pourront choisir ce qu'il en est pour leurs paquets&nbsp;: soit ils remplacent
>les paquets pas encore portÃ©s au fur et Ã  mesure, soit ils porteront tous leurs
>paquets Ã  la fois, ce qui est plus probable. BientÃ´t, Repoman n'acceptera plus
>aucun paquet ayant une dÃ©pendance pour virtual/x11.
></p>
>
><impo>
>Cela devrait permettre aux utilisateurs dits ~arch d'utiliser le X modulaire
>par dÃ©faut tout en envoyant les utilisateurs dits stables vers virtual/x11.
></impo>
>
></body>
></section>
></chapter>
>
><chapter>
><title>GÃ©rer les options de la variable USE</title>
><section>
><body>
>
><p>
>La plupart des gens n'a pas activÃ© l'option xinerama de la variable USE. Donc,
>si x11-proto/xineramaproto est affichÃ© comme une dÃ©pendance lorsque vous lancez
><c>included_headers.sh</c>, il vous faut l'ajouter Ã  DEPEND en correspondance
>avec l'option USE xinerama et ajouter x11-libs/libXinerama Ã  RDEPEND, lÃ  aussi
>en correspondance avec l'option USE xinerama.
></p>
>
><p>
>Caleb a soulevÃ© un point intÃ©ressant&nbsp;: comment gÃ©rer toutes les options
>USE sur les paquets qui ont des tonnes de dÃ©pendances optionnelles vers des
>bibliothÃ¨ques X&nbsp;? Dans de nombreux cas, ce sera une bonne mÃ©thode que de
>toujours forcer les options dans un Ã©tat donnÃ©. Aussi, vous pouvez rendre cela
>plus facile en groupant les options. Assurez-vous de nommer les options par
>leurs fonctions et non pas par les bibliothÃ¨ques ou les paquets qu'elles
>utilisent.
></p>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Faire entrer vos corrections dans l'arbre</title>
><section>
><body>
>
><p>
>Si vous Ãªtes dÃ©veloppeur, soumettez-les. Sinon, remplissez un nouveau rapport
>de bug, assignez-le aux mainteneurs du paquet (disponible dans le fichier
>metadata.xml).  Faites-le bloquer le bogue <uri
>link="http://bugs.gentoo.org/112675">#112675</uri>.  Attachez-y un correctif
>pour corriger les dÃ©pendances.
></p>
>
></body>
></section>
></chapter>
></guide>

Actions: View

Attachments on bug 120435: 78174 | 78175