Guide sur les ebuilds séparés de KDE

1.  Les ebuilds séparés de KDE

Ce qu'ils sont

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

• Pour installer un paquet particulier comme, par exemple, kmail, il suffit de faire un emerge kmail.
• Pour installer l'environnement KDE de base, qui vous permettra de vous connecter à une simple session KDE, il faudra faire un emerge kdebase-startkde.
• Enfin, pour disposer de l'équivalent exact de l'un des paquets monolithiques (par exemple, pour disposer de toutes les applications incluses dans kdebase en utilisant les ebuilds séparés), vous pouvez faire un emerge kdebase-meta (ou kdepim-meta, etc.). Pour disposer d'absolument tous les paquets KDE, faites un emerge kde-meta.

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.

Avantages des ebuilds séparés

Voici une liste rapide de ce que vous gagnerez à passer aux ebuilds séparés :

• La plupart des paquets KDE ne changent pas du tout entre deux sorties mineures de KDE. Par exemple, le passage de la version 3.3.1 à la 3.3.2 modifiera moins de 100 paquets sur 320. Les paquets séparés nous permettent de ne créer un nouvel ebuild uniquement lorsque l'application a effectivement subi des modifications, ce qui fait économiser (dans notre exemple) plus de deux tiers du temps de compilation lors de la mise à jour.
• Les correctifs n'affectent en général qu'un paquet bien précis. Avec les ebuilds séparés, ils peuvent être testés, approuvés et soumis plus rapidement et les développeurs ont moins de travail. Enfin, l'utilisateur final passera moins de temps à faire sa mise à jour. C'est important surtout pour les mises à jour de sécurité.
• Les utilisateurs d'autres bureaux ou gestionnaires de fenêtres peuvent installer les quelques applications KDE qui leur plaisent sans devoir passer par l'installation d'un gros paquet d'applications qu'ils n'utiliseront pas. Par exemple, kdebase ou kdepim.
• Les utilisateurs peuvent personnaliser au mieux les paquets qu'ils installent. Pourquoi ?
  • Vous vous préoccupez du temps de compilation. emerge kdebase kdepim kdenetwork prend bien trop de temps à compiler, surtout si vous ne souhaitiez que konqueror, kmail et kopete.
  • Vous vous préoccupez de l'espace disque. Chaque paquet non utilisé représente de l'espace disque bloqué et inutilisable sur votre disque. Un disque avec plus d'espace disque est préférable.
  • Vous vous préoccupez de la sécurité du système. Tous les logiciels installés sont des sources potentielles de vulnérabilité et il n'y a aucune excuse pour permettre de laisser des programmes inusités traîner sur votre système.
  • Vous adhérez complètement à la philosophie Gentoo et vous ne supportez pas d'avoir des applications regroupées par paquets qui obligent les utilisateurs à installer le tout.
• Enfin, les ebuilds séparés permettent plus de flexibilité, en ce qui concerne notamment les temps de compilation, grâce aux paramètres USE.

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.

2.  Problèmes de performance

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.

3.  FAQ des ebuilds séparés

Pourquoi est-ce que certains paquets séparés ne sont pas mis à jour lors de la sortie de nouvelles versions ?

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 :

• Il casse complètement le système de recherche de dépendances de Portage. Portage ne connaît pas DO_NOT_COMPILE et pense que l'ensemble du paquet monolithique a été installé et peut satisfaire les dépendances d'autres paquets. Cela peut amener ces autres paquets à ne pas pouvoir s'installer ou ne pas pouvoir s'exécuter.
• Il oblige l'utilisateur à connaître le nom et le sens de tous les différents sous répertoires des modules KDE. Peu d'utilisateurs en connaissent le sens, à moins d'être développeur KDE, vous avez peu de chances d'en faire partie. Il y a peu de chances pour que vous utilisiez alors DO_NOT_COMPILE correctement.
• Les sous-répertoires de modules KDE peuvent avoir des dépendances entre eux, nécessitent parfois un ordre précis de compilation, nécessitent la présence d'un autre répertoire même s'il n'a pas besoin d'être installé, etc. Nous avons passé beaucoup de temps sur les ebuilds séparés pour qu'ils puissent fonctionner correctement dans ce sens. DO_NOT_COMPILE n'est pas un outil assez fin pour obtenir des résultats aussi bons que les ebuilds séparés, même si l'utilisateur a une connaissance suffisante pour pouvoir le manipuler. La seule chose que cette variable vous permette de faire est d'enlever de la compilation quelques applications. Il est pratiquement impossible de l'utiliser pour installer deux ou trois applications à partir de modules comme kdebase ou kdepim.
• Si j'ai installé kmail hier et que je veux ajouter korn aujourd'hui, en utilisant DO_NOT_COMPILE, il faudra recompiler kmail également. Cela signifie que DO_NOT_COMPILE sera toujours plus lent que les ebuilds séparés.
• DO_NOT_COMPILE ne peut pas être utilisé pour créer des paquets précompilés (comme par exemple les GRP) contenant des applications individuelles de KDE.

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 :

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