Jusqu'à janvier 2005, les seuls ebuilds de KDE dans Portage étaient des ebuilds monolithiques. Il n'y avait qu'une quinzaine d'ebuilds et chacun installait de nombreuses applications (kdebase, kdenetwork...) qui, en réalité, ne dépendaient pas les unes des autres. Ce n'était vraiment une situation ni idéale, ni très conforme à l'esprit Gentoo, mais cela a été toléré pendant longtemps.
Les nouveaux ebuilds « séparés » (pour konqueror, kmail...) corrigent ce problème en proposant des ebuilds distincts pour toutes les applications de KDE. Cela donne un total d'environ 330 nouveaux ebuilds dans la catégorie kde-base.
Nous continuons cependant à proposer des ebuilds monolithiques pour KDE 3.5 (jusqu'à la version 3.5.9) et ils sont utilisables en conjonction avec les versions séparées. Cependant, les ebuilds séparés sont désormais la version par défaut et, après KDE 3.5.9, la version monolithique disparaîtra.
Enfin, il faut remarquer qu'il existe également des ebuilds séparés pour Koffice qui proposent kword, kugar, etc. comme des paquets distincts.
Comment installer des ebuilds séparés
À l'heure où ces lignes sont écrites, la dernière version de KDE mise à disposition est la 3.5.9. La dernière version instable (~arch) est la 3.5.10. Les ebuilds séparés et monolithiques pour ces deux versions sont disponibles dans Portage. La version 4.1.x est dans l'arbre en état masqué.
Comment mettre à jour des ebuilds monolithiques vers les séparés
Si les ebuilds monolithiques de KDE 3.4.x ou 3.5.x sont installés, vous devez les désinstaller avant d'installer les ebuilds séparés. Vous pouvez, si vous le souhaitez, effectuer l'opération pour chaque ebuild monolithique à tour de rôle. Vous n'avez pas besoin de désinstaller tous les ebuilds KDE à la fois.
Si vous avez un doute, souvenez-vous qu'il existe des dépendances bloquantes en place entre chaque ebuild monolithique et les ebuilds séparés dont ils dérivent. Portage ne permet pas de créer un état instable, donc toute installation ou désinstallation que Portage vous permettra de faire sera OK.
Voici une liste rapide de ce que vous gagnerez à passer aux ebuilds séparés :
Utilisation conjointe des ebuilds monolithiques et séparés
Les ebuilds monolithiques et séparés peuvent être librement mélangés. La seule restriction est qu'il ne faut pas installer un ebuild monolithique en même temps qu'un ebuild séparés qui en dérive. Des dépendances bloquantes empêchent de faire cela, donc vous pouvez faire tout ce qu'emerge vous permet de faire.
Cela dit, il n'y a normalement aucune raison pour que vous utilisiez une configuration mixte. En fait, mis à part certains cas comme la compilation sur des machines lentes, vous devriez plutôt utiliser les ebuilds séparés pour tout ce que vous souhaitez utiliser.
Les ebuilds séparés sont les ebuilds par défaut. Cela signifie que quand d'autres ebuilds dépendent d'une application KDE, ils essayeront d'installer l'ebuild séparé. Cela dit, l'ebuild monolithique correspondant devra également satisfaire cette dépendance, donc vous pouvez installer l'ebuild monolithique à la main, puis installer l'ebuild qui en dépend.
Pourquoi les ebuilds séparés sont lents ?
Il a été remarqué dans ce rapport de bogue que les ebuilds séparés sont plus longs à installer que leur version monolithique, à cause du fait qu'il faille désarchiver et lancer le script de configuration pour chaque paquet, au lieu d'un seul. Une installation complète avec emerge kde-meta devrait prendre entre 20 et 30% plus de temps qu'une installation classique de emerge kde, ce qui est difficilement acceptable pour une compilation qui prend déjà suffisamment de temps.
Pour couronner le tout, pour le moment, les ebuilds séparés lancent toujours un make -f admin/Makefile.cvs (ce qui signifie exécuter autoconf, automake, etc. et divers scripts spécifiques à KDE). Cela ajoute une dose de lenteur à la compilation, qui est du même ordre que l'exécution du script de configuration.
Enfin, un ebuild séparé doit extraire des fichiers spécifiques depuis une archive tar imposante. Ceci est plus lent que l'extraction d'une archive tar dédiée de plus petite taille. Cependant, créer de telles archives pour le système de compilation de KDE 3.x qui est basé sur les autotools est difficile.
Il est bon de rappeler ici que grâce aux ebuilds séparés, une mise à jour de KDE aura un temps de compilation bien inférieur à cette même mise à jour en utilisant les ebuilds monolithiques. Ces bénéfices masquent souvent les désagréments constatés lors de l'installation initiale.
Finalement, installer tout KDE n'a de sens que si vous voulez explorer et tester l'ensemble des paquets disponibles ou si vous voulez mettre en place un environnement multi-utilisateur. Cela dit, la plupart des utilisateurs n'utilisent qu'une poignée des plus de 300 applications KDE disponibles. Ceux qui se préoccupent sérieusement du temps de compilation, comme les propriétaires de vieilles machines, peuvent gagner plus de temps à choisir minutieusement les paquets à installer qu'à installer les ebuilds monolithiques.
Comment va-t-on faire pour accélérer tout ça ?
La plupart sinon tous les problèmes de performance des ebuilds séparés sont liés aux autotools - autoconf, automake et d'autres outils qui gèrent le processus de compilation (./configure;make;make install) de KDE 3.x.
KDE 4 a adopté un processus de compilation complètement différent, cmake, qui, entre autres choses, réduit considérablement le temps que prend son équivalent d'un make -f admin/Makefile.common; ./configure.
Comme expliqué précédemment, toutes les applications ne sont pas mises à jour entre deux versions mineures de KDE, et par conséquent toutes les applications ne voient pas la création d'une nouvelle version de leur ebuild. Par exemple, libkdenetwork n'a pas été modifiée pour la version 3.5.0_beta2, donc le dernier ebuild disponible porte le numéro de version 3.5_beta1.
Ceci est fait simplement pour réduire le temps de compilation lors d'une mise à jour. Si nous avions créé un ebuild libkdenetwork-3.5.0_beta2, cela aurait installé exactement les mêmes fichiers que l'ebuild pour la version 3.5_beta1. Les diverses dépendances sont mises à jour pour que tout fonctionne correctement (i.e. aucun ebuild ne dépendra de libkdenetwork-3.5.0_beta2).
Notez que, à cause de cela, si vous voulez installer des versions masquées de KDE, il se peut que vous ayez besoin de démasquer certains paquets d'une version précédente de KDE, s'ils sont également masqués. Veuillez lire ce bogue pour plus de détails.
Est-ce qu'on ne peut pas déjà faire ceci avec DO_NOT_COMPILE ?
DO_NOT_COMPILE est une variable d'environnement interne utilisée lors de la compilation de KDE. Elle permet de supprimer de la compilation certains sous-répertoires choisis à l'avance. Certains utilisateurs s'en servent pour ne compiler qu'une partie d'un ebuild KDE monolithique. Par exemple, exécuter DO_NOT_COMPILE=konqueror emerge kdebase devrait installer la base de KDE sans installer l'application konqueror.
Cependant, DO_NOT_COMPILE n'a jamais eu pour but de permettre d'intervenir dans les opérations de compilation du gestionnaire de paquets. Cela ne fonctionne pas correctement, peut casser votre système et n'a jamais été supporté. Nous demandons donc de ne surtout pas l'utiliser.
Voici quelques-uns des problèmes de DO_NOT_COMPILE :
Est-ce que vous n'en demanderiez pas un peu trop aux mainteneurs KDE de Gentoo ?
Curieusement, cette question est souvent revenue. Je suis content de voir que les utilisateurs sont aussi prévenants à l'égard des mainteneurs. Laissez-moi vous dire, pour l'occasion, que nous avons nous-même choisi la voie des ebuilds séparés. Nous croyons que nous seront capables de maintenir les paquets avec la même qualité qu'actuellement. Rien ne nous empêchera de faire les ebuilds séparés.
Pour être plus juste, je devrais ajouter que des mainteneurs d'autres architectures se sont effectivement plaints de l'augmentation de charge de travail, de tests et de gestion des mots-clefs sur autant d'ebuilds séparés. Nous travaillons actuellement pour résoudre ce problème et c'est la raison essentielle qui fait que les ebuilds monolithiques seront en fait toujours disponibles pour KDE 3.5.
Allez-vous supprimer les ebuilds monolithiques ?
Nous essaierons de le faire. Cela dit, pour toutes les versions de KDE 3.x jusqu'à la version 3.5.9, nous fournissons à la fois des ebuilds monolithiques et séparés. Pour KDE 3.5.10 et plus récents, ainsi que KDE 4 nous ne fournissons plus d'ebuilds monolithiques.
Si vous préférez les ebuilds monolithiques aux séparés, merci de nous faire part de vos raisons.
Il y a trop d'ebuilds ! Comment faire pour trouver celui dont j'ai besoin ?
Tout d'abord, si vous savez que le paquet que vous recherchez vient avec kdebase vous pouvez toujours faire un emerge kdebase-meta, qui vous permettra de faire un peu la même chose que si vous installiez la version monolithique de kdebase.
Évidemment, vous pouvez utiliser tous les moyens habituels de recherche de paquet. Trouveriez-vous votre ebuild si c'était une application Gnome ? Le minimum est d'avoir le nom de l'application que vous recherchez.
La situation pourrait peut-être être améliorée en ajoutant certains ebuilds de type -meta. Ils sont à considérer comme des listes de dépendances, donc ça ne nous coûte rien d'en créer. Mais nous n'avons pas encore décidé si nous le ferons ou pas. De même, il serait bien que Portage puisse supporter certaines fonctionnalités liées aux ebuilds -meta avant de se mettre à les utiliser de manière excessive.
Comment puis-je lister/désinstaller tous les ebuilds séparés qui dérivent d'un paquet donné ?
L'objectif ici est d'obtenir une liste de tous les ebuilds séparés de KDE dérivant de, mettons, l'ebuild monolithique kdebase. Encore une fois, une implémentation correcte (comme proposé dans la GLEP 21) pourrait rendre cette opération triviale. Mais, pour le moment, vous devrez jouer avec des détails qui concernent l'implémentation des eclass KDE. Donc si vous les utilisez pour un script qui n'est pas à usage privé, merci de nous le signaler.
kde-functions.eclass définit des fonctions nommées get-parent-package() et get-child-packages() qui font la traduction pour vous. Ces deux fonctions sont un bon moyen d'obtenir la liste demandée à partir d'un ebuild ou d'un script bash externe. Voici un exemple :
Exemple de code 3.1 : Exemple d'utilisation des fonctions de kde-functions |
$ function die() { echo $@; } # appelée pour afficher les erreurs $ source /usr/portage/eclass/kde-functions.eclass $ get-parent-package konqueror # ne fonctionnera pas, vous devez spécifier le nom complet Package konqueror not found in KDE_DERIVATION_MAP, please report bug # erreur affichée $ get-parent-package kde-base/konqueror # nom complet kde-base/kdebase # résultat affiché $ get-child-packages kde-base/kdebase (Une longue liste de paquets s'affiche ci-dessous.) |
Si votre script n'est pas en bash, vous pouvez récupérer dans kde-functions.eclass la définition (sur plusieurs lignes) de la variable KDE_DERIVATION_MAP que les fonctions citées plus haut utilisent. Cette variable contient une liste de mots séparés par des espaces et chaque paire de mots consécutifs permet de faire la correspondance entre un paquet parent et un ebuild séparé qui hérite de celui-ci.
Ce document est protégé par la licence Creative Commons : Paternité - Partage des Conditions Initiales à l'Identique 2.5.