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
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.
$ 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
Le premier script,
Le second script,
Le troisième script,
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 », i.e. 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
Si vous spécifiez l'option
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éé.
Sur le fait d'ajouter les dépendances -- on veut une structure comme celle-ci :
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 )
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.
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
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.
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