LinuxPedia

Wiki libre et indépendant dédié à GNU-Linux et BSD.

Outils pour utilisateurs

Outils du site


gentoo:introduction-gentoo

— page corrigée — TheShift 2009/02/25 13:10

Introduction à Gentoo

Guides et Tutoriels Gentoo-Québec
PDF original

Introduction.

Au cours de cet article, nous allons apprendre qu'est-ce que Gentoo, le gestionnaire de paquets Portage et comment on doit l'utiliser de manière générale ainsi que les notions de base qu'on doit connaître sous Gentoo.

Gentoo, c'est une distribution GNU-Linux basée sur le code source des logiciels. De plus, Gentoo est considérée comme une “MetaDistribution”, car aucune installation ne va être identique, car on a le choix d'installer ce qu'on veut de A à Z en plus de définir notre niveau d'optimisation. Donc, contrairement aux distributions binaires, chaque installation de Gentoo peut différer.

Portage est le gestionnaire de paquets officiel sous Gentoo. C'est cela qui nous permet d'installer, de désinstaller et de mettre à jour notre distribution Gentoo. À la base, Portage vient du concept de ports sous FreeBSD, c'est-à-dire un système de gestion des dépendances géré par les sources des logiciels via le système de Ports. C'est un détail technique, mais ça résume bien la philosophie derrière ce gestionnaire de paquets.

De plus, Portage contient un arbre de dépendances qui contient tous les logiciels disponibles sous Gentoo. Portage utilise des fichiers de type .ebuild.

Pour pouvoir interagir avec Portage on doit utiliser la commande Emerge. Cette commande est le coeur du système Gentoo.

En effet, presque toute l'administration de notre système va passer par Emerge.

# emerge --info




Figure 1 : Résultat de la commande emerge –info

Si vous naviguez à travers les forums de Gentoo, lorsque quelqu'un a un problème, c'est une des premières choses que les gens vont demander, car on peut savoir l'état d'une installation en quelques secondes.

Comme on peut voir sur la figure 1, il y a beaucoup d'informations. On peut y retrouver, entre autres, les informations suivantes :

  • Le profile.
  • La version du noyau utilisé présentement.
  • La version du compilateur GCC.
  • La version de Portage.
  • Les variables CFLAG.
  • La variable Use.
  • La liste des serveurs de téléchargement.

Alors il va sans dire que c'est très important quand on doit débugger quelqu'un, car avec cela, on peut aider la personne sans qu'on ait besoin de se logguer en SSH.

Ceci nous amène à vous expliquer le coeur de Portage, car le retour de emerge –info résume en gros les fonctionnalités que Portage utilise.


Commençons par le commencement.

La première chose qu'il faut comprendre sous Gentoo, c'est que le gestionnaire de paquets contient un arbre de dépendances qui permet à Portage de se comporter adéquatement quand nous voulons installer/désinstaller ou mettre à jour un logiciel.

Alors quand nous voulons faire quelque chose sur notre système, on doit obligatoirement faire la commande suivante :

# emerge --sync




Figure 2 : Résultat de la commande emerge –sync

Cette commande va permettre de mettre à jour l'arbre de Portage et, par le fait même, cela permet de garder l'intégrité du gestionnaire de paquets.

Cette même commande permet aussi de rendre disponible de nouvelles versions de logiciels ou carrément de nouveaux logiciels qui sont maintenant dans l'arbre de Portage.

On utilise cette commande seulement une fois par jour, car il ne faut pas surcharger les serveurs.

Maintenant que vous savez comment synchroniser votre arbre de dépendances, nous allons décortiquer les informations de emerge –info et, par le fait même, nous allons voir environ 90% des notions de base que l'on doit connaître sous Gentoo.

Les Stages et les Snapshots.

L'installation d'une Gentoo requiert le téléchargement d'un fichier Stage et d'un Snapshot.

En effet, un Stage est en fait le système de base pour pouvoir installer Gentoo et le fichier Snapshot est en fait l'arbre de Portage qu'on va installer à la main.

Sous Gentoo, il existe 3 Stages présentement :

  1. Le Stage 1 est en fait un système qui permet de construire le toolchain de Gentoo à la main. Le tout sera expliqué plus longuement plus tard.
  2. Le Stage 2 est en fait un système qui contient déjà un toolchain compilé et on doit installer le système de base selon nos critères.
  3. Le Stage 3, c'est un système qui est déjà prêt à l'utilisation , car le toolchain a été compilé ainsi que le système de base. Donc, c'est ce Stage que tout le monde doit utiliser.


Figure 3 : Les Stages qui sont disponibles sous Gentoo.


Figure 4 : Les Snapshots qui sont disponibles sous Gentoo.

De plus, depuis quelque temps, le créateur de Gentoo Daniel Robbins met à disposition des Stages et des Snapshots à jour une fois par semaine au minimum. Ce sujet sera traité en détail plus tard dans ce document.

La notion de profile

Portage 2.1.4.4 (default/linux/x86/2008.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.26-gentoo-r1 i686)

Pour pouvoir installer avec succès une Gentoo, on doit déterminer le profile qu'on va utiliser.

# eselect profile list
  1. default-linux/x86/2006.1
  2. default-linux/x86/2006.1/desktop
  3. default-linux/x86/2007.0
  4. default-linux/x86/2007.0/desktop
  5. hardened/x86/2.6
  6. selinux/2007.0/x86
  7. selinux/2007.0/x86/hardened
  8. default/linux/x86/2008.0
  9. default/linux/x86/2008.0/desktop *
  10. default/linux/x86/2008.0/developer
  11. default/linux/x86/2008.0/server
  12. hardened/linux/x86

Le profile 2008.0 : ce profile permet d'utiliser la version courante de Gentoo sans interface graphique.

Le profile 2008.0/desktop : ce profile est utilisé quand nous voulons utiliser la version courante de Gentoo sur un ordinateur ou un portable et qu'on veut utiliser une interface graphique.

Le profile 2008.0/Server : ce profile est utilisé quand nous voulons utiliser la version courante de Gentoo sur un serveur.

Une petite note à propos du profile desktop. Ce profile existe depuis la version 2006.1, car avant, il y avait tellement de monde qui avaient des problèmes avec le profil Standard qui contenait des Use Flags de base que les développeurs ont fait un profil pour que tout le monde ait une base solide pour avoir une interface graphique par défaut.

Le profile Hardened : ce profile est utilisé pour ceux qui ont des serveurs de production ou des serveurs Web. C'est le profile le plus sécuritaire sous Gentoo et le plus conservateur par le fait même.

Donc, le seul fait d'avoir choisi un mauvais profile peut expliquer pourquoi un Serveur X refuse de démarrer.

C'est banal, mais comme c'est Gentoo, il faut que tout soit parfait pour que ça fonctionne.

Le Use Flag.

Cette petite variable est vraiment l'essence même de Gentoo, car cette variable représente à elle seule la philosophie de Gentoo qui est de laisser le choix à l'utilisateur.

Qu'est-ce qu'un Use Flag : un Use Flag, c'est en fait une option qu'on peut activer pour toute notre Gentoo ou pour certains packages.

Le meilleur exemple est le suivant : si par exemple dans le fichier /etc/make.conf, on a une variable USE qui contient ceci :

USE="kde -gnome"

On doit interpréter cela de la manière suivante : On indique à Portage que notre système va utiliser KDE et qu'on veut rien savoir de Gnome et si par hassard un package a une option qui pourrait activer une fonctionnalité servant pour le bureau Gnome, Portage va s'occuper de désactiver cette option pour ne pas avoir cette option sur notre système.

Prenez note que la variable USE située dans /etc/make.conf va intervenir sur tous les packages du système.

Cela implique qu'on doit parler du fonctionnement interne de la variable Use Flag

Fonctionnement des Use Flags.

En effet, sous Gentoo, une variable Use peut se retrouver à 4 endroits différents et indépendamment de l'endroit, il y a une gestion des priorités qui s'effectue.
Sous Gentoo, la variable Use interagit dans un processus en 4 étapes :

Étape 1.
Dans chaque profile il y a des valeurs de Use Flags par défaut qui sont définies dans le make.defaults qui pointe en fait sur le profile choisi. Alors on peut se retrouver avec des options par défaut et c'est très bien dans plusieurs cas.
Un exemple qui va expliquer le tout :
Le profile 2008.0/desktop contient le Use Flag X tandis que le profile 2008.0 ne le contient pas.

Étape 2.
La variable Use qui est dans le fichier /etc/make.conf
En plus d'avoir celles qui sont définies dans le profile, on peut activer ou désactiver globalement un Use Flag.

Étape 3.
La variable Use dans le fichier /etc/portage/package.use
Cette variable aura une portée seulement sur le package sélectionné. Nous verrons en détail son fonctionnement plus tard.

Étape 4.
La variable Use définie en tant que variable d'environnement à l'aide de la commande export.
Cette dernière n'est presque jamais utilisée en fait.
Donc, pour résumer le tout, plus le # de l'étape est élevé, plus sa priorité est grande sur les autres.
Un petit exemple :
http://www.gentoo-portage.com/net-wireless/iwlwifi/USE#ptabs
On peut voir qu'on peut ajouter le Use Flag IPW3945.
Je sais très bien que ce Use Flag n'est pas présent dans le profile 2008.0/desktop.
J'ai le choix de l'ajouter dans le fichier /etc/make.conf pour qu'il soit pris en compte globalement ou j'ai le choix de l'ajouter localement au package iwlwifi.
De plus, si on a l'esprit tordu, on peut faire ceci :
Ajouter à la variable Use dans /etc/make.conf USE=“-ipw3945”
Ajouter le Use Flag ipw3945 dans le fichier /etc/portage/package.use
Qu'est-ce que vous pensez que ça va donner ? Si vous avez répondu que le package iwlwifi va se faire compiler quand même avec le Use Flag, vous pouvez continuer à lire la suite :-)

L'utilisation de Portage dans la vie de tous les jours.

Lorsqu'on utilise Gentoo, la commande emerge faisant partie intégrante de Gentoo va devenir notre amie au quotidien.
En effet, emerge contient toutes les commandes nécessaires pour administrer notre Gentoo et ainsi la faire évoluer.
Au cour de cette introduction, nous allons utiliser l'exemple suivant :

Commande 1 :

# emerge --sync

Commande 2 :

# emerge -auDNv world

Commande 3 :

# emerge -fuDNv world

Commande 4 :

# emerge -uDNv world

Commande 5 :

# dispatch-conf

Commande 6 :

# revdep-rebuild

Commande 7 :

# emerge -p --depclean

Les 7 commandes représentent une mise-à-jour standard. Nous allons voir en détail chacune d'elle:

Commande 1 :

# emerge --sync

Comme vu précédemment, cette commande permet de mettre à jour l'arbre de Portage et ainsi s'assurer de l'intégrité de celui-ci.

Commande 2 :

# emerge -auDNv world

Cette commande permet de vérifier s'il y a des mises à jour disponibles.

  • La lettre a signifie ask : soit vérifier ce que la commande retourne sans rien changer et on répond Yes pour exécuter la commande ou no pour refuser la mise à jour.
  • La lettre u signifie update : soit activer la mise à jour des packages
  • La lettre D signifie deep : soit activer la mise à jour des packages ainsi que tous les packages qui en sont dépendants.
  • La lettre N signifie new use : soit si vous avez ajouté/modifié un Use Flag ou que le profile que vous utilisez a changé un Use, cette option permet de vérifier si la recompilation de certains packages est nécessaire.
  • La lettre v signifie verbose : soit afficher le plus possible d'informations lors du processus.

Commande 3 :

# emerge -fuDNv world

Cette commande est identique en tous points, sauf qu'on va télécharger tous les fichiers avant de lancer la maj.

  • La lettre f signifie fetch only : soit activer le téléchargement des différents packages.

Commande 4 :

# emerge -uDNv world

Cette commande est identique en tous points sauf qu'on exécute la maj.

Commande 5 :

# dispatch-conf

Cette commande permet de mettre à jour certains fichiers de configuration, car Portage ne mettra jamais à jour un fichier de configuration sans votre intervention. Donc, lorsqu'il y a un message à cet effet, vous devez lancer la commande dispatch-conf.

Commande 6 :

# revdep-rebuild

Cette commande permet de s'assurer lors de la mise-à-jour qu'il n'y a pas eu de dépendances qui ont été brisées, car il arrive parfois que cette situation arrive. La pire maj dans ce sens est sans contredit la maj de Expat en 2007.
En effet, la maj de ce package avait cassé plusieurs packages et ceux qui n'avaient pas fait la commande « revdep-rebuild » on eu beaucoup de problèmes à retrouver un système stable après un redémarrage de l'ordinateur. J'ai eu des problèmes moi aussi, même si j'avais lancé un « revdep-rebuild » avant de rebooter.
http://forums.gentoo.org/viewtopic-t-575655-highlight-expat+hell.html
C'est un des sujets les plus importants sur le forum.

Commande 7 :

# emerge -p --depclean

Cette commande permet d'enlever des packages qui ne servent plus ou qui n'ont plus de dépendance avec d'autres packages. Cette commande doit être vérifiée à chaque fois, car il n'est pas rare que depclean veuille effacer les sources du noyau ou, pire encore, un package que vous utilisez mais qui est considéré comme orphelin.
Note : le mot world va être expliqué beaucoup plus loin :-P

Voici les commandes lorsqu'on veut installer et désinstaller un logiciel en particulier :

Commande 8 :

# emerge [nom du package]

Commande 9 :

# emerge -C [nom du package]

Commande 10 :

# emerge -s [nom du package]

Commande 11 :

# emerge --searchdesc [nom du package]

Nous allons voir en détail chacune d'elle:

Commande 8 :

# emerge [nom du package]

Cette commande permet d'installer un package en particulier.

Commande 9 :

# emerge -C [nom du package]

Cette commande permet desinstaller un package en particulier.

Commande 10 :

# emerge -s [nom du package]

Cette commande permet chercher un package en particulier dans l'arbre de portage.

Commande 11 :

# emerge --searchdesc [nom du package]

Cette commande permet chercher un package à partir de la description (très long):

Utilisation de la commande equery

Tout d'abord, vous devez vous assurer que vous avez installé le package gentoolkit

# emerge -v gentoolkit

Commande 1 :

# equery belongs path_avec_exécutable

Commande 2 :

# equery check nom_du_ebuild

Commande 3 :

# equery depends nom_du_ebuild

Commande 4 :

# equery depgraph nom_du_ebuild

Commande 5 :

# equery files nom_du_ebuild

Commande 6 :

# equery hasuse nom_du_Use_Flag

Commande 7 :

# equery size nom_du_ebuild

Commande 8 :

# equery uses nom_du_ebuild

Commande 9 :

# equery which nom_du_ebuild

Nous allons voir en détail chacune de ces commandes :

Commande 1 :

# equery belongs path_avec_exécutable

Permet de retrouver le ebuild qui a installé le fichier sélectionné.

Commande 2 :

# equery check nom_du_ebuild

Sert à vérifer le md5 du package.

Commande 3 :

# equery depends nom_du_ebuild

Sert à savoir les packages qui dépendent du ebuild recherché. Cette fonction est très pratique lorsqu'on veut se débarrasser d'une ancienne librairie et que portage veut toujours la réinstaller lors de la mise à jour du système.

Commande 4 :

# equery depgraph nom_du_ebuild

Affiche un arbre de dépendance.

Commande 5 :

# equery files nom_du_ebuild

Liste les fichiers qui appartiennent au ebuild.

Commande 6 :

# equery hasuse nom_du_Use_Flag

Affiche tous les packages qui utilisent ce Use Flag.

Commande 7 :

# equery size nom_du_ebuild

Affiche la taille occupée du package sur le disque dur.

Commande 8 :

# equery uses nom_du_ebuild

Affiche les Use Flag que le ebuild peut utiliser.

Commande 9 :

# equery which nom_du_ebuild

Donne le path du ebuild en question.

L'arbre de Portage.

L'arbre de Portage est composé de 4 branches bien distinctes.

En effet, il y a les branches Stable, Testing, HardMask et Overlay.

Nous allons voir en détail chacune d'elles.

Stable : cette branche représente la branche stable de Gentoo. La plupart des personnes utilisent cette branche dans la vie de tous les jours.

Testing : cette branche représente les programmes qui sont encore en attente, car ils n'ont pas été encore testés à fond ou parce qu'il existe encore des bugs qui doivent être corrigés. Plus tard, nous verrons les possibilités qui s'offrent à nous pour les activer.

HardMask : cette branche représente les programmes qui viennent d'arriver dans l'arbre de Portage et ils doivent être testés à fond et la plupart du temps ils ont des bugs connus qui ne sont pas encore corrigés.

Overlay : cette branche est vraiment très spéciale, car elle contient des packages qui ne sont pas officiellement dans l'arbre de Portage. En effet, on peut installer un arbre de packages à côté de celui de Portage. Le tout fonctionne très bien. Plus tard, nous verrons les possibilités qui s'offrent à nous pour activer ceux-ci.

Pour votre information, certains packages arrivent dans les Overlays pour ensuite passer successivement par les branches Hardmask, Testing et Stable.

L'Overlay le plus populaire présentement, c'est le KDE-SVN, car il contient KDE 4.1 et même certains packages de la version 4.2.

Vous pouvez le consulter ici : http://genkdesvn.mailstation.de/

De plus, le plus impressionnant, c'est qu'un Overlay peut être public ou privé. En effet, les développeurs de Gentoo peuvent rendre publics leurs Overlays, comme dans le cas de fait KDE-SVN, ou carrément un développeur peut développer ses packages dans son coin et ainsi se créer un Overlay local sur son ordinateur personnel.

Pour votre information, ceux qui connaissent Debian on peut faire le comparatif suivant :

Gentoo Debian
Stable Stable
Testing Testing
HardMask SID
Overlay Experimental
Gestion de l'arbre.

Maintenant que vous connaissez les 4 branches, je vais vous expliquer comment on peut les gérer.

Tout d'abord, Portage met à notre disposition 3 processus pour activer une branche au complet ou l'activer seulement sur certains packages.

1/. La variable ACCEPT_KEYWORDS dans /etc/make.conf
Par défaut, cette variable va avoir la valeur suivante :

ACCEPT_KEYWORDS="x86" ou ACCEPT_KEYWORDS="amd64"

Cela indique très clairement qu'on veut rester dans la branche stable à tout prix.
Par contre, si on a la valeur suivante :

ACCEPT_KEYWORDS="~x86" ou ACCEPT_KEYWORDS="~amd64"

Cela indique très clairement qu'on veut passer dans la branche Testing.
Certaines personnes veulent fonctionner toujours avec les dernières versions des logiciels et ils sont prêts à utiliser cette branche.
Vous devez être connaisseur si vous utilisez cette option, car il peut arriver à l'occasion que le système ne soit pas stable du tout.
De plus, vous aurez toujours beaucoup de maj à effectuer, car cette branche est très active.
Donc, si vous changez cette variable, elle aura un impact sur tout le système.

2.Le fichier /etc/portage/package.keywords
Par défaut, ce fichier est vide et il sert exclusivement à activer une version Testing d'un logiciel en particulier.


Figure 5 : Exemple de fichier /etc/portage/package.keywords

Par exemple, on peut voir que j'accepte d'avoir un version en Testing du logiciel Amsn.

net-im/amsn ~x86

De plus, il est à noter qu'on peut même indiquer à Portage qu'on accepte seulement d'installer une version Testing en particulier :

=net-wireless/wlassistant-0.5.7 ~x86

Dans cet exemple, on indique qu'on accepte seulement la version 0.5.7 du package wlassistant.
De plus, en utilisant cette manière de fonctionner, on s'assure que le package wlassistant va un jour avoir une version supérieure 0.5.7 qui va un jour être incluse dans la branche Stable et par le fait même, on s'assure qu'un jour ou l'autre le package va être reconsidéré comme étant stable.
Ça nous permet ainsi d'assurer une intégrité.

3.Le fichier /etc/portage/package.unmask
Par défaut, lorsqu'on package arrive dans l'arbre officiel de Gentoo, il doit obligatoirement passer une période de temps dans la branche Hardmask.
De plus, si un développeur trouve un bug important dans un package qui se trouve dans la branche Stable ou Testing,il n'est pas rare que ce package soit déplacé dans la branche Hardmask.
Pour connaître la raison de la présence d'un package dans la branche Hardmask, je vous conseille de consulter le fichier suivant :

/etc/portage/package.mask

Ceci va avoir pour effet de transférer le package de la branche HardMask vers la branche Testing.
De plus, vous allez devoir insérer le package dans le fichier /etc/portage/package.keywords pour pouvoir l'installer.
En résumé, on peut utiliser la méthode à la pièce en utilisant les fichiers /etc/portage/package.keywords et /etc/portage/package.unmask.
Et si on veut y aller globalement, on utilise le fichier /etc/make.conf pour arriver à nos fins.

/etc/portage/package.unmask




L'installation de programmes binaires.

Certains packages permettent d'installer une version pré-compilée d'un logiciel. C'est le cas d'openoffice.org qui peut être compilé ou installé comme un fichier rpm ou deb avec la commande :

# emerge openoffice-bin




Packages virtuels.

Certains packages sont dits virtuels. Cela veut dire qu'ils offrent une fonctionnalité quelconque qui peut être fournie par plusieurs packages différents. Par exemple, un package peut fournir

“opengl”. Deux packages ne peuvent pas supporter la même fonctionnalité et être installés sur le système en même temps. Par exemple, libflash et gplflash ne peuvent pas être installés en même temps. Si on tente d'installer gplflash alors que libflash est déjà installé, alors portage va afficher un message ressemblant à :

!!! Error: the gnome-base/bonobo-activation package conflicts with another package.
!!! both can't be installed on the same system together.
!!! Please use 'emerge --pretend' to determine blockers.




Les slots.

Certaines librairies / programmes sont incompatibles entre deux versions. Ce n'est pas grave comme des programmes comme firefox, mais ca l'est pour des librairies comme glib. La version 1.0 de glib est incompatible avec la version 2.0. Normalement, il n'y a pas de problèmes, mais certains programmes prennent un temps assez énorme avant d'être mis à jour, ce qui fait qu'il faut souvent avoir deux versions d'une même librairie pour supporter certaines applications.
On peut voir qu'un package est installé ou va être installé en tant que slot si emerge -a affiche quelque chose qui ressemble à : [ NS ]


Utilisation des services (daemons).

Les scripts permettant de lancer les services se trouvent dans le répertoire /etc/init.d. Les fichiers de configuration utilisés par les services se trouvent dans le répertoire /etc/conf.d.
Pour démarrer, arrêter ou relancer un service.

# /etc/init.d/nom du service start
# /etc/init.d/nom du service pause
# /etc/init.d/nom du service stop

Pour savoir le status d'un service.

# /etc/init.d/<nom du service> status

Si on sait qu'un service est arrêté, mais la commande status indique qu'il roule encore, alors on doit faire ceci :

# /etc/init.d/nom du service zap




Configuration du démarrage du système.

Procédure de démarrage du noyau.

Le bootloader charge l'image du kernel et il démarre le noyau. Optionnellement, il charge le fichier initrd qui contient des modules qui doivent être chargés immédiatement (sans être obligé d'avoir le support du disque). Ensuite, il lance le process Init.Ensuite le fichier /etc/fstab est exécuté et les scripts placés dans /etc/init.d sont lancés.Quand tous les scripts sont exécutés, les terminaux sont lancés et on arrive à la fenêtre login.

Les scripts lancés dans /etc/init.d sont lancés en premier s'ils ont un lien symbolique dans /etc/runlevels/boot. Ensuite c'est ceux qui ont un lien symbolique dans /etc/runlevels/default.

Il y a 3 niveaux d'exécution interne :sysint,shutdown et reboot.

Il y a 4 niveaux d'exécution définie par l'utilisateur : boot, default, nonetwork et single. nonetwork sert quand on ne veut pas de connexion réseau.

Single est utilisé pour résoudre un problème.

Le programme rc-update permet d'ajouter ou d'enlever un service avec un niveau d'exécution dans la séquence de démarrage :

# rc-update del nom du service default
# rc-update add nom du service default
# rc-update show




Configuration des variables d'environnement.

Les variables d'environnements sont définies dans /etc/env.d
Le script env-update permet de créer et/ou de mettre à jour les variables d'environnement :

# env-update \&\& source /etc/profile

PATH : Cette variable contient la liste des répertoires séparés par des “:” dans lesquels le système cherche des fichiers exécutables.


Configuration à la pièce des Use Flags.

Comme vu précédemment, la variable Use interagit dans un processus en 4 étapes.
Le fichier /etc/portage/package.use permet d'activer un Use Flag au niveau d'un package en particulier.


Figure 6 : Exemple de fichier /etc/portage/package.use

Comme un exemple vaut mille mots, nous allons prendre le logiciel Audacious.
En effet, comme vous pouvez le constater, j'ai activé le support Flac pour Audacious et Audacious-plugins. Je ne voulais pas activer le support Flac globalement, car je me sers de Audacious comme lecteur audio et je veux écouter des fichiers de type .Flac seulement avec ce logiciel en particulier.
C'est cette subtilité qu'il faut bien comprendre.


La variable CFLAGS.Le Bootstrapping.

Sous Gentoo, on peut configurer tout manuellement et l'optimisation du compilateur GCC n'échappe pas à cette règle.
En effet, Gentoo met à notre disposition des paramètres pour activer toute la puissance de notre processeur.
Il existe une liste de Safe Flags pour activer en toute sécurité le plus de puissance possible concernant notre processeur : http://gentoo-wiki.com/Safe_Cflags
Pour notre exemple, j'utilise un portable T60P qui a un Intel Core 2 Duo T7200 :


Figure 7 : Exemple de résultat pour un processeur Core 2 Duo T7200

Selon le lien sur le site de Gentoo Wiki, si nous utilisons une Gentoo en 32 bits, nous devons avoir ces valeurs :

CHOST="i686-pc-linux-gnu"
CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"
CXXFLAGS="${CFLAGS}"

En gros, ça va permettre de compiler plus rapidement et surtout on s'assure d'avoir la puissance maximale lorsqu'on roule sous Gentoo.


Le Bootstrapping.

Tout d'abord, qu'est-ce que c'est ?
Le bootstrapping à l'origine c'est un environnement qu'on construit à la main pour permettre de compiler les outils de base et ainsi on construit notre Gentoo par la suite.
Ce projet à été abandonné en 2005, car c'était beaucoup trop compliqué de le faire à la main.
Pour ceux qui veulent lire le tout, voici le lien: http://www.gentoo.org/doc/en/draft/bootstrapping-guide.xml
En termes clairs, il s'agit des outils de base qui permettent de construire notre Gentoo, soit en anglais le Toolchain. Il est composé des packages suivants :
BinUtils, le compilateur GCC, GlibC ainsi que plusieurs autres logiciels.

De plus, lorsqu'on lance la commande suivante :

# emerge -e system

Cela va lancer la compilation des programmes suivants :

[ebuild R ] sys-apps/portage-2.1.4.4
[ebuild R ] dev-util/pkgconfig-0.23
[ebuild R ] virtual/libintl-0
[ebuild R ] sys-libs/zlib-1.2.3-r1
[ebuild R ] sys-devel/gnuconfig-20080123
[ebuild R ] virtual/libiconv-0
[ebuild U ] app-arch/lzma-utils-4.32.6 [4.32.5] USE="-nocxx%"
[ebuild R ] dev-libs/expat-2.0.1
[ebuild R ] app-misc/pax-utils-0.1.17
[ebuild R ] sys-devel/gcc-config-1.4.0-r4
[ebuild R ] dev-libs/gmp-4.2.2-r2
[ebuild R ] sys-devel/autoconf-wrapper-4-r3
[ebuild R ] sys-devel/automake-wrapper-3-r1
[ebuild R ] app-admin/python-updater-0.5
[ebuild R ] sys-apps/sandbox-1.2.18.1-r2
[ebuild R ] dev-util/unifdef-1.20
[ebuild R ] sys-libs/timezone-data-2008c
[ebuild R ] sys-apps/tcp-wrappers-7.6-r8
[ebuild R ] sys-devel/patch-2.5.9
[ebuild R ] app-arch/bzip2-1.0.5-r1
[ebuild R ] app-arch/cpio-2.9-r1
[ebuild R ] sys-kernel/linux-headers-2.6.23[ebuild R ] dev-libs/libpcre-7.7-r1
[ebuild R ] dev-libs/mpfr-2.3.1
[ebuild R ] sys-apps/sysvinit-2.86-r10
[ebuild R ] net-misc/iputils-20071127
[ebuild R ] virtual/init-0
[ebuild R ] sys-apps/debianutils-2.28.5
[ebuild R ] sys-apps/baselayout-1.12.11.1
[ebuild R ] sys-fs/udev-124-r1
[ebuild R ] sys-apps/man-pages-3.05
[ebuild R ] sys-devel/binutils-config-1.9-r4
[ebuild R ] sys-auth/pambase-20080318
[ebuild R ] sys-devel/gettext-0.17
[ebuild R ] sys-devel/m4-1.4.11
[ebuild R ] sys-devel/binutils-2.18-r3
[ebuild R ] sys-apps/sed-4.1.5-r1
[ebuild R ] sys-apps/findutils-4.3.13
[ebuild R ] sys-devel/flex-2.5.33-r3
[ebuild R ] sys-apps/diffutils-2.8.7-r2
[ebuild R ] dev-libs/popt-1.10.7
[ebuild R ] sys-apps/grep-2.5.1a-r1
[ebuild R ] app-arch/gzip-1.3.12-r1
[ebuild R ] sys-apps/net-tools-1.60-r13
[ebuild R ] sys-apps/kbd-1.13-r1
[ebuild R ] sys-apps/gawk-3.1.5-r5
[ebuild R ] app-arch/tar-1.20
[ebuild R ] sys-devel/make-3.81
[ebuild R ] sys-libs/db-4.5.20_p2
[ebuild R ] sys-devel/bison-2.3
[ebuild R ] sys-apps/module-init-tools-3.4
[ebuild R ] sys-libs/gdbm-1.8.3-r3
[ebuild R ] sys-devel/libperl-5.8.8-r2
[ebuild R ] dev-lang/perl-5.8.8-r5
[ebuild R ] perl-core/Test-Harness-3.10
[ebuild R ] perl-core/PodParser-1.35
[ebuild R ] dev-perl/Locale-gettext-1.05
[ebuild R ] sys-apps/help2man-1.36.4
[ebuild R ] sys-apps/man-1.6f-r1
[ebuild R ] app-i18n/man-pages-fr-2.39.0
[ebuild R ] sys-apps/man-pages-posix-2003a
[ebuild R ] sys-devel/autoconf-2.61-r2
[ebuild R ] sys-devel/automake-1.10.1
[ebuild R ] sys-devel/libtool-1.5.26
[ebuild R ] x11-misc/util-macros-1.1.5
[ebuild R ] sys-apps/attr-2.4.41
[ebuild R ] x11-proto/xproto-7.0.10
[ebuild R ] sys-apps/acl-2.2.47
[ebuild R ] x11-libs/xtrans-1.0.3
[ebuild R ] x11-proto/kbproto-1.0.3
[ebuild R ] x11-proto/xextproto-7.0.2
[ebuild R ] x11-proto/xf86bigfontproto-1.1.2
[ebuild R ] x11-proto/inputproto-1.4.2.1
[ebuild R ] x11-proto/bigreqsproto-1.0.2
[ebuild R ] x11-proto/xcmiscproto-1.1.2
[ebuild R ] x11-libs/libXau-1.0.3
[ebuild R ] net-misc/rsync-3.0.3
[ebuild R ] x11-libs/libXdmcp-1.0.2
[ebuild R ] x11-libs/libICE-1.0.4
[ebuild R ] x11-libs/libX11-1.1.4
[ebuild R ] x11-libs/libSM-1.0.3
[ebuild R ] x11-libs/libXext-1.0.3
[ebuild R ] x11-libs/libXt-1.0.5
[ebuild R ] x11-libs/libXmu-1.0.3
[ebuild R ] x11-apps/xauth-1.0.2
[ebuild R ] sys-libs/ncurses-5.6-r2
[ebuild R ] sys-apps/texinfo-4.11-r1
[ebuild R ] app-shells/bash-3.2_p33
[ebuild R ] sys-apps/coreutils-6.10-r2
[ebuild R ] sys-libs/gpm-1.20.1-r6
[ebuild R ] app-editors/nano-2.1.2-r1
[ebuild R ] sys-apps/less-418
[ebuild R ] sys-process/psmisc-22.6
[ebuild R ] sys-process/procps-3.2.7
[ebuild R ] sys-libs/readline-5.2_p12-r1
[ebuild R ] app-admin/perl-cleaner-1.05
[ebuild R ] sys-apps/groff-1.19.2-r1
[ebuild R ] virtual/editor-0
[ebuild R ] sys-apps/which-2.19
[ebuild R ] virtual/pager-0
[ebuild R ] sys-devel/bc-1.06.95
[ebuild R ] sys-libs/com_err-1.40.9
[ebuild R ] sys-libs/ss-1.40.9
[ebuild R ] app-crypt/mit-krb5-1.6.3-r1
[ebuild R ] sys-fs/e2fsprogs-1.40.9
[ebuild R ] sys-apps/util-linux-2.13.1.1
[ebuild R ] dev-libs/openssl-0.9.8g-r2
[ebuild R ] dev-lang/python-2.5.2-r6
[ebuild R ] app-misc/ca-certificates-20080514-r2
[ebuild R ] net-misc/wget-1.11.3
[ebuild R ] sys-libs/cracklib-2.8.12
[ebuild R ] dev-libs/libxml2-2.6.32
[ebuild R ] sys-apps/file-4.23
[ebuild R ] sys-libs/pam-1.0.1
[ebuild R ] sys-apps/shadow-4.0.18.2
[ebuild R ] sys-apps/busybox-1.8.2
[ebuild R ] net-misc/openssh-4.7_p1-r6
[ebuild R ] sys-devel/gcc-4.1.2
[ebuild R ] sys-libs/glibc-2.6.1

Comme on peut voir, il y a beaucoup de packages.
Cela permet de recompiler le toolchain en plus du système de base.
Pour les puristes, nous devons recompiler le toolchain 2 fois, puisque selon la commande

# emerge -ae system

la compilation de GCC s'effectue à la fin du processus. Donc, la première fois qu'on va compiler le toolchain, presque tous les packages vont être compilés avec les options par défaut du compilateur et quand Gcc va se faire compiler, tous les autres packages vont utiliser nos nouveaux paramètres, soit ceux qui viennent de la variable CFLAGS.
Donc, c'est une compilation semi-toolchain.

Alors les puristes vont utiliser cette commande :

# emerge -e system && emerge -e system

Ceci va compiler tous les packages avec les bons paramètres d'optimisation de GCC.
Il y a tellement eu de discussions à propos de ce principe qu'il fallait en glisser un mot au passage.


L'impact de la variable Use dans Portage.

Comme vous le savez, la variable Use permet d'activer ou de désactiver un paramètre ou une fonctionnalité d'un programme.
Par contre, physiquement, voici ce qui se passe à l'interne.
Voici une description du ebuild de iwlwifi. Le programme n'est pas important, c'est seulement le principe qui compte dans cet exemple : http://www.gentoo-portage.com/net-wireless/iwlwifi

# Copyright 1999-2007 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/net-wireless/iwlwifi/iwlwifi-1.2.23.ebuild,v 1.1 2008/01/22 05:08:58 compnerd Exp$

inherit eutils linux-mod DESCRIPTION="Intel (R) PRO/Wireless Network Drivers"
HOMEPAGE="http://intellinuxwireless.org/?p=iwlwifi"
SRC_URI="http://intellinuxwireless.org/${PN}/downloads/${P//_p/-}.tgz"

LICENSE="GPL-2"
SLOT="0"
KEYWORDS="~amd64 ~x86"
IUSE="ipw3945 ipw4965"
DEPEND="|| ( =virtual/linux-sources-2.6.22* =virtual/linux-sources-2.6.23* )"
RDEPEND="ipw3945? ( =net-wireless/iwl3945-ucode-2.14.1.5 )
         ipw4965? ( =net-wireless/iwl4965-ucode-4.44.1* )
        !ipw3945? ( !ipw4965? ( =net-wireless/iwl3945-ucode-2.14.1.5 =net-wireless/iwl4965-ucode-4.44.1* ) )"

Une notion très importante, c'est que si nous ajoutons le Use Flag ipw3945 de manière globale (/etc/make.conf) ou locale (/etc/portage/package.use), la ligne :

RDEPEND="ipw3945? ( =net-wireless/iwl3945-ucode-2.14.1.5 )

indique très clairement que si nous avons le Use ipw3945, l'installation du package iwlwifi va aussi installer le package net-wireless/iwl3945-ucode.salut

Le même comportement s'applique pour le Use ipw4965, car s'il est activé, l'installation du package iwlwifi va aussi installer le package net-wireless/iwl4965-ucode.
Tandis que si vous n'avez pas spécifié de Use Flag pour ce package, il va installer les 2 packages net-wireless/iwl3945-ucode et net-wireless/iwl4965-ucode à cause de la ligne suivante :

!ipw3945? ( !ipw4965? ( =net-wireless/iwl3945-ucode-2.14.1.5 =net-wireless/iwl4965-ucode-4.44.1* ) )"

C'est seulement une courte introduction au fichier .ebuild, car cela fera partie d'un article spécifique.


Le projet Funtoo.org.

Le projet Funtoo a été créé par Daniel Robbins quand le projet Gentoo a eu une “guerre interne” en 2007.0. En effet, durant cette année là, il y a beaucoup de développeurs qui sont partis et même le fondateur de Gentoo s'est fait montrer la grande porte. Pour mettre un peu d'huile sur le feu, mon ami Daniel a démarré le site Funtoo.org et il propose des Stages et des Snapshots de Portage de manière presque quotidienne dans le but de limiter les maj à la suite d'une nouvelle installation.
C'est très pratique quand on est pressé et surtout, il a voulu montrer qu'il peut aider Gentoo tout en travaillant seul et quoi de mieux que de rendre disponibles les Stages pour montrer qu'il sait encore comment elle fonctionne, sa distribution :-P
Donc, vous pouvez vous servir de ces Stages et de ces Snapshots de manière transparente. Ceci va être pratique quand le Stage courant va prendre de l'âge surtout quand vous allez vouloir installer une Gentoo avec un Stage et un Snapshot qui datent de 6 mois. Vous allez avoir beaucoup de maj si vous n'utilisez pas cette méthode.


Figure 8 : Le site Web de funtoo.org


Que faire quand le cd d'installation de Gentoo ne fonctionne pas ?

Tout d'abord, on sèche ses larmes.
En fait, si vous voulez essayer le LiveCD de Gentoo, il vous faut essayer le minimal CD de Gentoo qui est disponible ici : http://www.gentoo.org/main/en/where.xml
À remarquer que le minimal CD supporte plusieurs architectures tandis que le LiveCD supporte seulement les versions i686 (32 bits) et Amd64 (pour les processeurs 64 bits Intel et AMD, il faut préciser).
Si après avoir essayé les 2 versions, ça ne fonctionne pas encore, vous avez une très belle alternative qui s'offre à vous.
En effet, l'installation d'une Gentoo, contrairement à plusieurs autres distributions sur le marché, on peut l'installer à partir d'une autre distribution ou carrément on peut utiliser un LiveCD de Knoppix ou un LiveCD de Ubuntu pour arriver à installer notre distribution favorite.
Petit détail technique : 90% du temps, lorsque le CD de Gentoo refuse de fonctionner, c'est parce que vous avez un ordinateur récent et le noyau qui est inclus dans le CD de Gentoo n'est pas assez récent pour détecter convenablement votre matériel.
Depuis quelques mois, en fait depuis que le profile 2008.0 a été retardé en 2008, il y a un LiveCD qui est devenu très populaire.
Il se nomme SystemRescueCD et il est disponible ici : http://www.sysresccd.org/Index.fr.php.
C'est en fait un Gentoo Minimal CD qui contient un Serveur X. Le plus grand avantage d'utiliser celui-ci, c'est qu'il n'y a aucun impact au niveau de l'installation d'une Gentoo.
Enfin, il utilise toujours des noyaux très récent, car les développeurs de ce LiveCD aiment que leur LiveCD puisse booter sur n'importe lequel des ordinateurs.


Les Overlays.

Comme dit précédemment, un Overlay c'est une branche de Portage qui n'est pas officiellement supportée. En effet, elle sert essentiellement pour les développeurs qui développent des logiciels et qui sont en attente pour arriver dans la branche Hardmask.
De plus, il y a 2 types d'Overlays :

  1. Public : c'est un Overlay qu'un développeur rend disponible pour tous les utilisateurs de Gentoo qui ajoutent cet Overlay en particulier.
  2. Privé : c'est un Overlay local qui réside sur l'ordinateur de la personne.

Une caractéristique très importante : tous les packages qui sont dans des Overlays peuvent avoir la mention Stable ou Testing ~Arch seulement.
Donc, si un jour vous voulez installer un package particulier et qu'il n'est pas disponible, vous devez ajouter une entrée dans /etc/portage/package.keywords pour ajouter la mention ~Arch (x86 ou AMD64) et là il va apparaître.
Si vous voulez en savoir plus, je vous conseille d'aller ici : http://overlays.gentoo.org
C'est ici qu'on peut voir ce que contiennent tous les Overlays présentement.
Si vous voulez en savoir plus, je vous conseille d'aller ici : http://overlays.gentoo.org
C'est ici qu'on peut voir ce que contient tous les Overlays présentement.

Pourquoi utiliser un Overlay ?

Il existe plusieurs raisons pour utiliser un Overlay. Voici les raisons principales :

  1. Lorsqu'on modifie manuellement un ebuild, la prochaine fois qu'on va faire un emerge –sync, nous allons perdre notre modification.
  2. Lorsqu'un développeur teste un nouveau logiciel ou une nouvelle version d'un logiciel, il ne veut pas compromettre l'arbre de Portage, donc il fait ses modifications dans une branche à part de celui de Portage.
  3. Pour tester des nouveautés expérimentales et surtout être capable d'installer avec succès des logiciels qui ne sont pas prêts à être intégrés dans la branche Hardmask de Portage. Par exemple, la venue d'une nouvelle version de KDE a un impact sur beaucoup de logiciels qui dépendent de celui-ci et ils utilisent un Overlay pour stabiliser le logiciel en question ainsi que toutes ses dépendances. Par la suite, dans ce cas particulier, il va pouvoir se faire intégrer à la branche Hardmask.

Comment utiliser un Overlay ?

Tout d'abord, pour utiliser un Overlay, on doit utiliser le logiciel Layman qui est responsable de la gestion de ceux-ci.

# emerge --sync
# emerge -v layman
# echo "source /usr/portage/local/layman/make.conf" >> /etc/make.conf

Ceci va installer le nécessaire pour que Portage puisse voir la 4ème branche.
Par la suite, vous devez lancer la commande suivante pour voir si vous voyez les Overlays qui sont disponibles :

# layman -L

Pour ajouter un Overlay en particulier, vous devez lancer la commande suivante :

# layman -a <nom_du_Overlay>

Par la suite, vous devez lancer la commande suivante pour mettre à jour votre arbre de Portage :

# emerge --sync && layman --sync ALL

Enfin, vous faites comme d'habitude pour installer et mettre à jour vos logiciels, car l'intégration des Overlays est transparente dans Portage.


Ceci conclu cette courte introduction à Gentoo.


Retour à la page Gentoo

gentoo/introduction-gentoo.txt · Dernière modification: 2018/11/17 12:53 (modification externe)