Créer son profile

Le profil est situé dans /etc/make.profile. Cette destination n’est en faite qu’un lien symbolique qui va dans /usr/portage/profiles/default-linux/arch/nom_du_profil. Un profil est donc tout un ensemble de fichiers qui sert à portage. Il sert à déterminer la version de Gentoo. Par exemple, pour avoir une Gentoo 2004.3, il faut gcc-3.3.4-r1 binutils-2.14.90.0.8-r1..etc. Mais vous vous n’êtes pas forcement censé savoir qu’il faut ces versions et pas les autres, c’est pourquoi l’équipe de Gentoo a mis un système de profil en marche.

C’est très simple, si vous voulez créer un serveur avec Gentoo dessus, vous voudriez peut-être une autre version de gcc et de glibc par exemple... avec des USE bien particuliers.. une version de Portage 2.0.50. Mais il n’y a pas que pour la création d’un serveur, mais aussi pour le testeur, il installe un système entier hautement instable avec les toutes dernières versions. On pourrait passer des heures à citer d’autres exemples mais continuons.

Reprenons l’exemple du serveur. Vous voulez installer une Gentoo avec les versions de votre choix des applications systèmes (glibc, binutils..) qui soit exactement la même sur vos quatres serveurs, avec un profil, c’est faisable.

Quand vous mettez à jour votre Gentoo, vous faites tous les jours, tous les semaines ou voir tous les mois, un emerge —sync pour le téléchargement du dernier arbre portage et ensuite un emerge -u world pour faire une mise à jour de votre Gentoo. Sauf que cette mise à jour est toujours en accord avec le profil, c’est-à-dire que si le profil indique que cette version ne doit pas être mise à jour, elle n’y sera pas.

Si vous voulez que votre Gentoo soit parfaitement à jour, il faut donc envisager de changer de profil quand un nouveau sort. La manipulation est assez simple :

Gentoo nous propose quelques profils. Ci-dessous, sur le tableau, vous verez quelques exemples de profils avec leurs noms et leurs caractéristiques.

Avant de nous précipiter à créer le profil, vous allez devoir réfléchir à la version des paquets à installer.

Ensuite, nous allons créer un répertoire qui va s’appeller Mon_Profil.

# mkdir ~/Mon_Profil

Tous les fichiers que nous créeront par la suite seront obligatoirement dans ce répertoire, alors il est peut-être préférable de se placer tout de suite dans Mon_Profil.

# cd ~/Mon_Profil

Pour commencer, nous allons créer le fichier deprecated qui sert à indiquer si votre profil est désapprouvé. Ce fichier ne va nous servir mais je vais vous monter comment s’en servir. Cette manipulation est qu’à titre d’exemple, il ne faut pas le créer. D’abord, créeons le fichier deprecated.

La première ligne, default-linux/x86/2004.3, sert à dire quel est le profil a mettre à jour par dessus le profil désapprouvé. Les quatres autres lignes précise comment le mettre à jour.

Quand vous avez un profil désapprouvé, voici le message que Portage, vous envoie :

Vous retrouvez bien, default-linux/x86/2004.3 à mettre à jour et avec l’indication de la manipulation pour le mettre à jour.

Note :Le fichier deprecated ne sert donc qu’à prevenir l’utilisateur qu’il utilise un profil désapprouvé. Il ne jouera pas sur le système.

Dans ce fichier, vous allez devoir préciser quelques variables. En faite, toutes les variables qui vont dans le fichier /etc/make.conf peuvent s’inscrire aussi ici. Six variables en plus sont un peu spéciales pour ce fichier :

• ARCH="x86"
• Type d’architecture de l’ordinateur (x86/sparc/hppa/pcc etc...) USERLAND = GNU
• Support BSD/cygwin/etc... PORTAGE_LIBC = glibc
• Support uClibc/BSD libc/etc... PROFILE_ARCH="sparc32"
• Distingue les classes de machines qui ont la même architecture. Par exemple, toutes les machines sparc ont comme variable ARCH=sparc mais peuvent s’appeler sparc32 ou sparc64. STAGE1_USE="apm arts avi"
• Drapeaux USE spéciales qui peuvent être nécessaires quand vous amorcez du stage1 au stage2. GRP_STAGE23_USE="berkdb gpm"
• Drapeaux USE spéciales utilisés par catalyst pour construire un stage3 et régler GRP.

Je vous conseille si vous créez un profil pour plusieurs serveurs de ne pas placer ARCH dans ce fichier mais plutôt dans le fichier /etc/make.conf car je ne pense pas que vous aurez les mêmes serveurs.

Ce fichier comporte une liste compléte de paquets qui peuvent être installés. Vous pouvez bien entendu préciser des versions. Par exemple :

Vous pouvez également ajouter des paquets à la base du système lui-même si vous les mettez avec un * en en-tête.

*sys-apps/baselayout

Vous metterez dans ce fichier, packages.build, la liste de paquets qui seront installés dans le stage1. Il est utile seulement quand vous voulez construire un stage.

Ici, nous n’allons surtout pas définir des drapeaux USE par défaut. En faite, nous allons définir des USE qui corresponderont à des paquets. Par exemple :

tcltk      dev-lang/tcl   dev-lang/tk

En d’autres termes, si jamais j’installe le paquet dev-lang/tcl et dev-lang/tk, Portage m’inscrira directement la USE tcltk dans la variable USE.

Note : Pour chaque drapeau USE définit, vous pouvez préciser à coté plusieurs paquets.

Dans ce fichier, c’est très simple, vous préciserez tout bétement les USE que vous voulez masquer.

Comme ca, les paquets n’utiliseront jamais les drapeaux USE 3dnow, afs, alsa, ifc et mmx.

Prenons un exemple simple, dans le paquet kde-base, il demande comme dépendance virtual/x11, c’est-à-dire un serveur X. C’est dans ce fichier que l’on va définir ce qu’est virtual/x11. Pour ce choix là, il n’y a que deux paquets, soit x11-base/xorg-x11 ou soit x11-base/xfree. Par exemple, on choisit de mettre x11-base/xfree pour le virtual de x11 :

virtual/x11        x11-base/xfree

Note : Si vous créez pas mal de paquets, ceci est très pratique lorsqu’on veut les tester avec d’autres dépendances que celles par défauts.

Dans ce fichier, vous écrivez le chemin de l’annuaire des profils. Dans la plupart des cas, c’est ca :

..

Pour utiliser votre profil, il suffit de supprimer le profil actuel, et de faire un lien sur le nouveau :

Voila, tous les fichiers qui peuvent être utilisés pour la creation d’un profil mais ca ne veut pas dire qu’il faut obligatoirement tous les utiliser. Je vous conseille juste de prendre make.defaults, packages, parent, virtuals. Aprés cela dépend de ce que vous voulez faire.