FAQ Comment fonctionne emerge

Un article de Gentoo Linux Wiki.

FAQ

Général -- Système -- Wiki

Sommaire

[modifier] Introduction

Le but de ce cette documentation est d'expliquer ce qui se passe chronologiquement lors d'un emerge, en particulier pour que ceux qui feront leur premiers ebuild comprennent bien le phénomène de sandbox. Ils pourront être renvoyés vers cette documentation. Mon but n'est pas d'expliquer tous les réglages possibles, mais de faire comprendre sur un exemple comment le tout s'articule.

[modifier] Les principaux fichiers de configuration

  • /etc
    • /etc/make.globals les valeurs par défaut des paramètres de Portage.
    • /etc/make.conf la configuration principale utilisée par Portage, les paramètres supplantent ceux de make.globals lorsqu'ils sont réglés.
    • /etc/portage répertoire où l'on met les fichiers package.keywords, package.use, package.mask et package.unmask qui modifient le calcul des dépendances et les versions des paquets installés par emerge.
  • /usr/portage répertoire où se trouvent tous les ebuilds, chacun dans un répertoire de catégorie. On y trouve aussi:
    • /usr/portage/distfiles là où sont les archives contenant les sources des programmes que l'on a emergé, ou tenté d'emerger.
    • /usr/portage/profile et en particulier /usr/portage/profile/package.mask qui contient la liste des paquets masqués par défaut et /usr/portage/profile/{architecture}/virtuals qui sera expliqué plus loin.
    • /usr/portage/packages qui contient les paquets binaires .tbz2 créés grâce à quickpkg, lors d'un emerge -b ou lors d'un emerge d'un paquet important si on a le paramètre buildsyspkg dans FEATURES (que je conseille de mettre).
  • /var
    • /var/cache/edb/
      • /var/cache/edb/world le fichier world (/var/lib/portage/world à partir de Portage-2.0.51)
      • /var/cache/edb/virtuals le fichier virtuals (n'existe plus à partir de Portage-2.0.51).
        Le fichier virtuals sert au calcul des dépendances. Par exemple fluxbox qui a besoin d'un serveur X peut se contenter de Xorg ou de Xfree indiféremment, il y a ainsi dans l'ebuild de fluxbox une dépendance sur virtual/x11. Si une ligne virtual/x11 x11-base/xorg-x11 est présente dans le fichier virtuals, alors la dépendance est bien présente. Cette ligne est rajoutée au fichier virtuals lors de emerge xorg-x11 car l'ebuild de xorg-x11 contient une ligne PROVIDE="virtual/x11". Enfin si on essaye d'emerger fluxbox sans avoir emergé un serveur X au préalable, aucune ligne virtual/x11 n'est présente dans le fichier virtuals et emerge décider d'installer un paquet qui "fournit" virtual/x11, et il choisit ce paquet grâce au fichier /usr/portage/profile/{architecture}/virtuals qui contient les paquets à installer par défaut.
        Si emerge -upD world a tout le temps envie de vous réinstaller des sources de noyau dont vous ne voulez plus c'est qu'il faut nettoyer à la main ce fichier...
    • /var/db/pkg contient toutes les informations sur les paquets installés sur votre système, en particulier l'ebuild, les USE et les CFLAGS au moment de l'installation, le fichier CONTENTS qui contient la liste des fichiers installés par le paquet, et encore d'autres informations. La plupart des autres fichiers de configuration peuvent être reconstruit si on les perd ou casse, mais pas ce répertoire.

[modifier] Le fichier ebuild

Lors de emerge fluxbox emerge choisit par exemple d'utiliser /usr/portage/x11-wm/fluxbox/fluxbox-0.9.9.ebuild.
Voilà /usr/portage/x11-wm/fluxbox/fluxbox-0.9.9.ebuild pour référence :

Fichier : /usr/portage/x11-wm/fluxbox/fluxbox-0.9.9.ebuild 
# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/x11-wm/fluxbox/fluxbox-0.9.9.ebuild,v 1.16 2004/09/16 02:29:12 pvdabeel Exp $

inherit eutils

IUSE="nls xinerama truetype kde gnome"

DESCRIPTION="Fluxbox is a lightweight windowmanager for X featuring tabs."
SRC_URI="mirror://sourceforge/fluxbox/${P}.tar.gz"
HOMEPAGE="http://www.fluxbox.org"

# Please note that USE="kde gnome" simply adds support for
# the respective protocols, and does not depend on external libraries.
RDEPEND="virtual/x11
        truetype? ( media-libs/freetype )
        nls? ( sys-devel/gettext )"
DEPEND=">=sys-devel/autoconf-2.52
                ${RDEPEND}"
PROVIDE="virtual/blackbox"

SLOT="0"
LICENSE="MIT"
KEYWORDS="x86 ppc sparc amd64 alpha hppa ~ia64 mips ppc64 macos ppc-macos"

src_unpack() {
        unpack ${A}
        cd ${S}
        # upstream tell us we probably want to apply this if there's any chance
        # anyone will ever try to compile using gcc 3.4.
        epatch ${FILESDIR}/${PN}-0.9.9-gcc3.4.patch
}

src_compile() {
        export PKG_CONFIG_PATH=/usr/X11R6/lib/pkgconfig:/usr/lib/pkgconfig
        econf \
                `use_enable nls` \
                `use_enable xinerama` \
                `use_enable truetype xft` \
                `use_enable kde` \
                `use_enable gnome` \
                --sysconfdir=/etc/X11/${PN} \
                ${myconf} || die "configure failed"

        emake || die "make failed"
}

src_install() {
        dodir /usr/share/fluxbox
        make DESTDIR=${D} install || die "make install failed"
        dodoc README* AUTHORS TODO* COPYING

        dodir /usr/share/xsessions
        insinto /usr/share/xsessions
        doins ${FILESDIR}/${PN}.desktop


        dodir /etc/X11/Sessions
        echo "/usr/bin/startfluxbox" > ${D}/etc/X11/Sessions/fluxbox
        fperms a+x /etc/X11/Sessions/fluxbox
}

Si vous voulez une vraie référence sur les ebuilds allez voir man 5 ebuild.
Un ebuild c'est ::

  • 3 lignes de commentaires générées automatiquement lorsqu'un developpeur envoie un paquet sur les serveurs.
  • inherit quelquechose pour charger des fonctionnalités en plus dans l'ebuild. Les plus courants et utiles sont :
    • eutils petits outils dont epatch
    • flag-o-matic pour enlever/changer des CFLAGS
    • cvs pour télécharger les sources d'une cvs
    • kde pour compiler quelquechose pour kde
    • gnome2 pour compiler quelquechose pour gnome2

Ces eclass sont des scripts situés dans /usr/Portage/eclass

  • des affectations de variables en particulier :
    • IUSE liste des drapeaux USE utilisés par l'ebuild
    • SRC_URI pour récupérer les sources (sauf pour le cvs)
    • DEPEND : la liste des dépendances
    • SLOT pour savoir si plusieurs paquets peuvent cohabiter avec des versions différentes. Par défaut SLOT="0" pour signaler qu'une seule version du paquet doit être installée à un instant T. un exemple très riche est gcc (je rappelle que etcat fait partie du paquet gentoolkit) :
Code : etcat sur gcc
# etcat -v gcc
 [ Results for search key           : gcc ]
 [ Candidate applications found : 24 ]

 Only printing found installed programs.

*  sys-devel/gcc :
                    [M I] 2.95.3-r8 (2.95)
                    [M  ] 3.1.1-r2 (3.1)
                    [   ] 3.2.3-r4 (3.2)
                    [M  ] 3.3 (3.2)
                    [M~ ] 3.3.1-r5 (3.2)
                    [M  ] 3.3.2 (3.2)
                    [M~ ] 3.3.2-r1 (3.2)
                    [M~ ] 3.3.2-r2 (3.2)
                    [M~ ] 3.3.2-r3 (3.2)
                    [M~ ] 3.3.2-r4 (3.2)
                    [   ] 3.3.2-r5 (3.2)
                    [M~ ] 3.3.2-r7 (3.2)
                    [M  ] 3.3.3_pre20040408-r1 (3.2)
                    [M  ] 3.3.3_pre20040426 (3.2)
                    [M~ ] 3.3.3 (3.2)
                    [M~ ] 3.3.3-r3 (3.2)
                    [M~ ] 3.3.3-r5 (3.2)
                    [   ] 3.3.3-r6 (3.2)
                    [  I] 3.3.4-r1 (3.2)
                    [M~ ] 3.3.4-r2 (3.2)
                    [M~ ] 3.4.1 (3.4)
                    [M~ ] 3.4.1-r2 (3.4)
                    [M~ ] 3.4.1-r3 (3.4)
                    [M~ ] 3.4.2-r1 (3.4)

Le slot présent dans l'ebuild est ici affiché entre parenthèses. On voit que j'ai en même temps gcc-2.95.3-r8 et gcc-3.3.4-r1 d'installés, ce qui n'est possible que parce qu'ils sont dans des slots différents. Après il y a gcc-config pour passer d'un compilateur à l'autre... gimp est un autre exemple, mais là il n'y a pas de gimp-config, et la distinction se fait en appelant l'exécutable par gimp-1.2 ou gimp-2.0.

    • KEYWORDS pour signaler si le paquet est stable ou en test (avec un ~ )
    • d'autres qui sont nécéssaires, mais mieux expliquées ailleurs, comme par exemple dans le Ebuild Howto.
  • des fonctions telles src_compile() ou src_install() qui ont déjà des valeurs par défaut si on ne spécifie rien dans l'ebuild. un ebuild peut ainsi ne pas contenir de src_compile() si jamais la procédure par défaut spécifiée par Portage marche bien.

[modifier] Ce que emerge fait

Lors d'un emerge fluxbox (par exemple ...)

  • quel fichier ebuild utiliser ? On prend l'ebuild qui convient le mieux : l'ebuild ayant le numéro de version le plus élevé, non masqué et avec le bon keyword, et dans les overlay si il y a ambiguité. /usr/portage/x11-wm/fluxbox/fluxbox-0.9.9.ebuild est choisi.
  • quelles sont les dépendances ? Là emerge regarde les variables DEPEND pour les dépendances nécéssaires à la compilation et RDEPEND pour les dépendances nécéssaires à l'exécution de fluxbox (les Runtime dependancies)
Fichier : /usr/portage/x11-wm/fluxbox/fluxbox-0.9.9.ebuild 


RDEPEND="virtual/x11
        truetype? ( media-libs/freetype )
        nls? ( sys-devel/gettext )"
DEPEND=">=sys-devel/autoconf-2.52
                ${RDEPEND}"

Donc il nous faut autoconf, un serveur X, et si USE (de make.conf) contient truetype, alors il faut freetype, si USE contient nls, il faut gettext. On verra plus loin que USE n'influence pas que les dépendances

  • On installe les dépendances si ce n'est pas déjà fait. À cet instant on est prêt à installer fluxbox-0.9.9, et emerge fait comme si on exécutait la commande :
Code : Installation de fluxbox
ebuild /usr/portage/x11-wm/fluxbox/fluxbox-0.9.9.ebuild merge

(en gros, car en réalité ce n'est que l'étape principale du processus : par exemple le ebuild blabla merge ne nettoie pas les fichiers objets intermédiaires tout seul. Il faut faire un ebuild blabla clean, contrairement à emerge qui lui, nettoie si on lui laisse son comportement par défaut).

Lors de cette commande, la partie de compilation des sources, si elle a le droit de lire presque partout, est restreinte en écriture au répertoire /var/tmp/portage/fluxbox-0.9.9/ (en gros, car plus précisément il y a d'autres répertoires autorisés en écriture, d'autres où l'on fait croire que l'on a le droit d'écrire, etc... je vous conseille d'emerger sandboxshell pour être plus familier avec ces concepts). 

man 1 ebuild
merge Normally, to merge an ebuild, you need to fetch, unpack, compile, install and qmerge.
    • clean emerge nettoie les anciens essais de compilation : il vide le répertoire /var/tmp/portage/fluxbox-0.9.9/work/fluxbox-0.9.9.
    • fetch récupération des fichiers listés dans SRC_URI pour les mettre dans /usr/portage/distfiles.
    • setup exécute la fonction pkg_setup() si elle est présente dans l'ebuild (c'est rare).
    • unpack décompression des fichiers dans ${WORKDIR} c'est à dire /var/tmp/portage/fluxbox-0.9.9/work ou exécution de la fonction src_unpack() de l'ebuild. Typiquement elle est définie lorsqu'il faut appliquer des patchs (voir l'exemple plus haut).
    • compile exécute la fonction src_compile() de l'ebuild.
      Au début de cette fonction, on est dans ${S} c'est à dire /var/tmp/portage/fluxbox-0.9.9/work/fluxbox-0.9.9 et on effecture un ./configure puis un make à ceci près qu'il vaut mieux utiliser econf et emake, qui sont des fonctions définies par Portage. En effet econf est un configure auquel on a ajouté des options pour changer les répertoires d'installation de manière à ce qu'ils correspondent à ceux définis par gentoo et emake c'est make avec les options de MAKEOPTS (défini dans make.conf).

Ici intervienent pour la deuxième fois les drapeaux USE puisqu'ils conditionnent le econf. ainsi un use_enable kde est remplacé par un --enable-kde si kde est dans les USE, et par --disable-kde sinon.

    • install par défaut on effectue un make DESTDIR=${D} install (ici ${D}=/var/tmp/portage/fluxbox-0.9.9/image/ ) qui a pour effet de copier les fichiers compilés dans ${S} vers ${D} comme si ${D} était /.
      Je m'explique : grâce à l'affectation de DESTDIR, le fichier /var/tmp/portage/fluxbox-0.9.9/work/fluxbox-0.9.9/src/fluxbox, créé lors de emake, sera copié vers /var/tmp/portage/fluxbox-0.9.9/image/usr/bin/fluxbox, lors du make DESTDIR=${D} install.
      En effet, un simple make install échouerait car /usr/bin n'est pas en écriture à ce moment précis. Il est donc nécessaire de patcher les programmes qui ne reconnaissent pas la variable DESTDIR pour leur faire installer les fichiers quand même au bon endroit, c'est à dire dans la sandbox (par exemple l'ebuild pour darksnow de Corto et moi).
    • preinst exécute la fonction pkg_preinst() si elle est présente dans l'ebuild (c'est rare).
    • qmerge c'est lors de cette étape que les fichiers sont recopiés de ${D} vers / mais ils ne sont pas recopiés bêtement : le md5 de chaque fichier est calculé et enregistré avec son chemin final et sa date dans le fichier /var/db/pkg/${CATEOGRY}/${PN}-[version-rev]/CONTENTS c'est à dire /var/db/pkg/x11-wm/fluxbox-0.9.9/CONTENTS.
      Ces données sont utilisées lors de emerge unmerge.
      Petit traitement spécial pour les fichiers qui atterissent dans un répertoire protégé tel /etc (paramètre CONFIG_PROTECT, présent dans make.globals).
    • postinst exécute la fonction pkg_postinst() si elle est présente dans l'ebuild - c'est très souvent ici que des messages sont affichés à la fin de l'installation. On utilise einfo pour afficher ces petits messages.
    • clean on vide le répertoire /var/tmp/portage/fluxbox-0.9.9.
    • on ajoute catégorie/paquet au fichier world (et éventuellement au virtuals si ce paquet a une variable PROVIDE).

[modifier] emerge unmerge

emerge unmerge lit ce fichier CONTENTS et supprime les fichiers qui y sont répertoriés lorsque leur dates et leur md5 correspondent à celui donné dans la liste, et le laisse sinon ; et un emerge -u revient à emerger la nouvelle version puis à unmerger l'ancienne.
il exécute les fonctions pkg_prerm pkg_postrm de l'ebuild si elles sont présentes. Vous remarquerez que le vieil ebuild est gardé dans /var/db/pkg/x11-wm/fluxbox-0.9.9/fluxbox-0.9.9.ebuild.
C'est pourquoi etcat -v n'affiche pas toujours toutes les versions des paquets installés sur votre système, etcat -v n'affiche que les versions des paquets installés sur votre système et disposant d'un ebuild présent dans /usr/portage. Or les vieux fichiers ebuild sont enlevés de /usr/portage périodiquement. Ainsi les binaires installés par la nouvelle version du paquet ne sont pas désinstallés par le emerge unmerge de l'ancienne version du paquet.


C'est pas beau Portage ? :)



Le document original est sous licence FDL. Ce document doit donc être pris comme un document dérivé de l'original, selon les termes de la FDL. 

MaJ : 06/10/2004
Source : http://forums.gentoo.org/viewtopic.php?t=226855&
Auteur initial : scout
Récupérée de « http://fr.gentoo-wiki.com/FAQ_Comment_fonctionne_emerge »