Le fichier comps définit comment les paquets seront assemblés durant l'installation. Dans la distribution RedHat, ceci est fait selon la fonctionnalité qu'ils procurent, par exemple:
Support Imprimantes
Système X Window
GNOME
KDE
Outils Mail/WWW/News
...
Développement du Noyau
Documentation Supplémentaire
Quelquefois durant le processus d'installation, l'utilisateur se trouve face à une fenêtre appelée "Composants à installer". Quelques-uns des composants ont été présélectionnés, d'autres non. Le dernier point sur la liste des composants est appelé "Tout". Sur la fenêtre, il existe aussi une option qui permet à l'utilisateur de personnaliser très précisément la liste des paquets qui seront installés. Personnaliser l'installation à la main, ou sélectionner "Tout" dans la liste des composants est le seul moyen d'avoir vos propres paquets installés, sauf si vous modifiez le fichier RedHat/base/comps.
Le fichier comps commence avec un entête décrivant la version du format comps, suivie d'une ligne vide.
0.1 <empty line> |
Après ceci, les composants sont listés, séparés par des lignes vides:
<composant 1> <ligne vide> <composant 2> <ligne vide> .... <composant n> <ligne vide> EOF |
Chaque composant a la définition suivante:
(0|1) (--hide)? <name> <RPM 1> <RPM 2> ... <RPM n> end |
Avant le nom de chaque composant est placé un 0 ou un 1. Une valeur de 1 à cet endroit veut dire que le composant est choisi par défaut, et un 0 veut dire le contraire. L'option --hide veut dire que vous ne pouvez pas voir l'entrée, sauf si vous choisissez l'installation << en mode expert >>. Le premier composant est appelé << Base >>, et il est spécial, dans le sens où il doit être présent et qu'il n'apparait pas dans le dialogue (vous ne pouvez pas désélectionner l'installation de la base, ce qui est sensé). Suit une liste de paquets RPM appartenant à ce composant. Notez qu'il s'agit du nom du paquet stocké dans le fichier rpm, et non pas d'une partie du nom du fichier du paquet (bien qu'il doive être identique par convention).
En ajoutant vos paquets au fichier comps, vous pouvez personnaliser votre propre distribution, et vous assurer que vos paquets seront installés par défaut. Une chose à laquelle vous devez porter attention est l'interdépendance entre vos paquets, mais ici c'est à vous de jouer :-) Un mot pour vous prévenir: faites attention de ne pas ajouter ou supprimer les espaces blancs supplémentaires dans le fichier. Examinez le fichier comps existant (faites une copie de l'original) pour voir comment il est fait (ou vérifiez i386/misc/src/install/pkgs.c si vous voulez voir comment le fichier est analysé).
Avec RedHat version 6.1, le format du fichier comps a changé. Le décodage s'effectue dans ${RHROOT}/${ARCH}/misc/src/anaconda/comps.py. Je n'ai pas encore analysé ce script python et les règles suivantes ont été obtenues seulement en lisant le fichier comps et en testant quelques configurations.
Dans la release 6.1, la définition du composant est étendue pour inclure quelques éléments optionnels supplémentaires avant les <RPM>. Ces élements sont:
<RPM-dépendant-de-architecture 1> ... <RPM-dépendant-de-architecture n> <composant-requis 1> ... <composant-requis n> <RPM-composant-dépendant 1> ... <RPM-composant-dépendant n> |
Un <RPM-dépendant-de-architecture> définit une dépendance entre un paquet et une architecture spécifique et a la définition suivante:
(!)?arch: <RPM> |
Donc il peut, par exemple, se présenter, dans le monde réel, comme:
!alpha: kernelcfg |
Ou comme:
i386: mkbootdisk |
Un <composant-requis> renforce la dépendance avec un autre composant et il est défini comme:
@ <component> |
Donc, par exemple, si à l'intérieur de la définition d'un composant, vous trouvez la ligne suivante:
@ Station Réseau |
Un <RPM-composant-dépendant> est utilisé pour sélectionner l'installation de quelques paquets additionnels pour un composant, étant donné la présence d'un autre composant. Sa définition est la suivante:
? <composant> { <RPM 1> ... <RPM n> } |
Donc si, par exemple, dans la définition d'un composant, il vous arrive de lire les lignes suivantes:
? KDE { kpppload } |
Avec RedHat version 6.2, le format du fichier comps a apparemment un peu changé. Le décodage se fait aussi dans ${RHROOT}/${ARCH}/misc/src/anaconda/comps.py. Encore une fois, je n'ai pas analysé ce script python et les règles suivantes ont été obtenues seulement en lisant le fichier et en testant quelques configurations.
Dans la release 6.2, la définition du composant est étendue pour inclure deux éléments optionnels supplémentaires:
<RPM-dépendant-language 1> ... <RPM-dépendant-language n> <composant-dépendant-architecture 1> ... <composant-dépendant-architecture n> |
Un <RPM-dépendant-language> est nécessaire pour spécifier l'installation d'un paquet au cas où une langue spécifique a été sélectionnée. C'est défini ainsi:
(lang <language>): <RPM> |
Par exemple, la ligne suivante
(lang ja_JP)): locale-ja |
Un <composant-dépendant-architecture> étend le concept du <RPM-dépendant-architecture>, introduit lors de la release 6.1, au composant entier, comme vous pouvez le comprendre à la lecture de sa définition:
(!)?arch: <component> |
Avec la RedHat version 7.3, le format du fichier comps a gagné en syntaxe. Le décodage prend place (encore) dans le script comps.py, que vous pouvez maintenant trouver dans le répertoire /usr/lib/anaconda/ si vous avez installé le paquet anaconda. Les dépendances sur une langue ou sur une architecture pour un composant ou un paquet peuvent maintenant être liées avec l'opérateur and. Par exemple:
(arch !s390 and arch !s390x and arch !ia64): readline2.2.1 |
ce qui veut dire que si l'architecture n'est ni s390, ni s390x, ni ia64, alors il faut installer le paquet readline2.2.1. Ceci peut être fait avec des composants au lieu des paquets, et avec des langues à la place des architectures. Tout ceci est définitivement plus qu'assez pour les simples exemples de personnalisation de l'installation par défaut qui seront présentés dans la prochaine section.
L'exemple que nous allons parcourir dans cette section implique des modifications dans le fichier comps pour changer les valeurs par défaut qui concernent l'installation des paquets. Je préfère habituellement, particulièrement dans certaines situations, une installation par défaut incluant seulement les paquets de base, avec quelques légères modifications pour certains d'entre eux. Dans le premier des exemples présentés, nous construirons une installation par défaut qui ajoute libsafe au composant << Base >>, dont la plupart des paquets, qui sont généralement installés par défaut, sont déselectionnés, dans le but de construire une installation minimale. Dans le second des exemples, nous modifierons quelques-uns des composants pour construire une autre installation minimale qui remplit nos besoins (cette fois, pratiquement parfaitement; ce sont, en fait, mes besoins, les vôtres peuvent varier). Si vous voulez inclure un fichier comps modifié dans vos CDs, vous devez le copier dans l'arbre principal juste avant de lancer reconstruire l'installateur 7.3 ou 8.0.
Pour personnaliser votre installation de cette façon, vous devez éditer le fichier comps avec votre éditeur de texte favori (faites attention à ne pas laisser d'espaces ou de tabulations dans ce fichier) et le déplacer dans le répertoire Redhat/base en écrasant l'original.
Dans le premier fichier comps inclus, le paquet libsafe était ajouté dans le composant << Base system >> et presque tous les composants étaient désélectionnés pour obtenir une installation par défaut comportant seulement 200 paquets (je sais qu'ils sont encore trop nombreux).
Nous construisons le deuxième fichier comps ci-joint à partir de l'étape précédente, pour réduire un peu plus l'installation par défaut (cette fois, il n'y aura plus que 154 paquets dans l'installation par défaut). Quelques-uns des groupes ont été divisé pour donner à l'installation plus de granularité. Toutes les modifications que vous faites doivent prendre en compte les interdépendances entre paquets et les applications utilisées durant les phases d'installation (vous ne pouvez pas supprimer kudzu, par exemple, du composant Base, même si vous pouvez le faire après installation). Il doit être dit que des résultats similaires peuvent être obtenus en utilisant kickstart. Pour plus d'informations à ce propos, vous pouvez lire le Guide de Personnalisation de RedHat Linux.
Avec la RedHat version 8.0, le format du fichier comps a été complètement changé et on utilise maintenant un fichier XML, nommé comps.xml. Les détails sur la syntaxe du fichier peuvent être trouvés dans la section anaconda comps du site web de RedHat.
Nous reproduirons maintenant les exemples présentés pour la release 7.3 en prenant en compte les modifications soumises aux différents groupes. Le groupe le plus important (le groupe << Base >>, divisé ici en deux groupes nommés << Base >> et << Core >>) doit représenter l'installation minimale.
Cette fois, pour personnaliser votre installation, vous devez éditer le fichier comps-milan.xml.in avec votre éditeur de texte favori. Le fichier peut être trouvé dans l'archive comps-8.0.tar.gz sur le site web de RedHat. Pour ajouter les informations de paquets au fichier que vous venez de créer, vous avez besoin d'avoir installé le paquet rpm comps-extras. Les commandes à lancer pour terminer les opérations sont listées dans mettre à jour comps.xml et dans la documentation. Après avoir créé le fichier, vous devez le copier dans le répertoire Redhat/base en écrasant l'original. Si vous utilisez le script updateBuild.sh, vous devez seulement copier comps-milan.xml (après avoir modifié comps-milan.xml.in qui se trouve dans le paquet tar/gzip comps-8.0.tar.gz et lancé la commande make), à l'emplacement que vous avez déjà configuré dans la variable COMPSFILE (dans rhcd.conf).
Dans le premier fichier comps ci-joint, le paquet libsafe a été ajouté au groupe (composant) << Base >> et pratiquement tous les groupes (composants) ont été déselectionnés, sauf << Base >> et << Core >>, pour avoir une installation par défaut de seulement 220 paquets environ (probablement trop nombreux, encore une fois).
Nous construisons le deuxième fichier comps ci-joint sur la précédente configuration et réduisons un peu plus l'installation par défaut (cette fois, il restera seulement 158 paquets de l'installation par défaut). Encore une fois, des résultats similaires peuvent être obtenus en utilisant kickstart, pour plus d'informations à ce propos, vous pouvez lire le Guide de Personnalisation de la RedHat Linux. Dans cet exemple, je n'ai pas désélectionné complètement l'installation du groupe, parce qu'il y a trop de paquets que j'utilise, donc j'ai juste désélectionné l'installation par défaut pour ces paquets en les rendant optionnels. Comme vous pouvez le voir, même le paquet redhat-logos dans le groupe << Base >> a été rendu optionnel. En considérant que les paquets présents dans ce groupe doivent représenter la plus petite installation possible, vous ne voudrez probablement pas le faire (de plus, mes CDs fonctionnent même ainsi; il doit exister quelques problèmes que je n'ai pas encore détectés). La dernière modification visible a été faite au groupe << dialup >>, qui sera installé même s'il est désélectionné, parce que le groupe << core >> en dépend (ce qui est indiqué dans la définition du groupe lui-même).