Porter un ebuild vers X modulaire

1. Environnement

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 ; ce sont leurs développeurs qui ont décidé de séparer tous ces paquets, et nous ne faisons que suivre.

Vous pouvez lire les détails à ce sujet dans le Guide de migration vers X.Org modulaire.

2. Contrôle des dépendances

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.

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 « INVALID ».

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.

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.

Exemple de code 2.1 : Obtenir les scripts nécessaires

$ wget http://dev.gentoo.org/~dberkholz/scripts/linking_libs.sh \
  http://dev.gentoo.org/~dberkholz/scripts/included_headers.sh \
  http://dev.gentoo.org/~betelgeuse/scripts/deputils/checkdeps.rb \
  http://dev.gentoo.org/~betelgeuse/scripts/deputils/pkgutil.rb

Important : Ne pas utiliser gentoolkit-0.2.1_pre9, cela donne des sorties invalides. Consultez https://bugs.gentoo.org/show_bug.cgi?id=111501.

Le premier script, linking_libs.sh, 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. Vous pouvez obtenir un journal de compilation, vous devriez soit définir la variable PORT_LOGDIR dans le fichier /etc/make.conf, soit rediriger l'affichage vers un fichier.

Exemple de code 2.2 : Exécuter linking_libs.sh pour le paquet gdm

$ ls /var/log/portage/*gdm* -l
-rw-r--r-- 1 root portage 556551 2006-01-09 11:41 /var/log/portage/8430-gdm-2.8.0.7.log
-rw-r--r-- 1 root portage    855 2006-01-09 11:42 /var/log/portage/8431-gdm-2.8.0.7.log
$ linking_libs.sh /var/log/portage/8430-gdm-2.8.0.7.log

Le second script, included_headers.sh, scanne le code source de votre paquet à la recherche de lignes commençant par #include et extrait les noms des fichiers inclus entre <>. Depuis le 9 septembre 2005, cela marche aussi pour les inclusions de type "".

Le troisième script, checkdeps.rb, scanne les fichiers installés par un paquet en utilisant scanelf, 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, pkgutil.rb, est une dépendance de checkdeps.rb.

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 : cela pourrait être une « fausse dépendance », c-à-d. une bibliothèque liée sans raison. Un exemple connu de dépendance de ce type est libXt ; de nombreux paquets cherchent les fichiers d'en-tête de libXt lorsqu'ils cherchent X.

Parfois, la recherche de fichiers d'en-tête relatifs de included_headers.sh 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.

Si vous spécifiez l'option -d, il arrivera parfois qu'une bibliothèque ou qu'un fichier d'en-tête soit noté « Not found! ». 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.

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.

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.

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 ;il y a un serveur DirectFB (xdirectfb) ; kdrive fournit des serveurs X légers ; et bien sûr, les vieux <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 « virtual » soit créé.

3. Structure de dépendance

Sur le fait d'ajouter les dépendances -- on veut une structure comme celle-ci :

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

Important : Certains résultats fournis par les scripts seront 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 faut 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 libXaw, libXmu, libXpm, libXcursor, libXt. Faites simplement un emerge -ep $library | grep lib[SIX]. N'oubliez pas non plus que d'autres paquets comme gtk+ ont été portés pour les dépendances modulaires, donc ils peuvent fournir les bibliothèques nécessaires.

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.

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.

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

Important : 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.

4. Gérer les options de la variable USE

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 included_headers.sh, 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.

Caleb a soulevé un point intéressant : comment gérer toutes les options USE sur les paquets qui ont des tonnes de dépendances optionnelles vers des bibliothèques X ? 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.

5. Faire entrer vos corrections dans l'arbre

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 #112675. Attachez-y un correctif pour corriger les dépendances.

Ce document est protégé par la licence Creative Commons : Paternité - Partage des Conditions Initiales à l'Identique 2.5.