Handbook:HPPA/Portage/Advanced/fr
Introduction
Pour la plupart des utilisateurs, les informations reçues jusqu'à présent sont suffisantes pour toutes leurs opérations Linux. Mais Portage est capable de beaucoup plus ; bon nombre de ses fonctionnalités sont destinées aux utilisateurs avancés ou ne sont applicables que dans certains cas particuliers. Pourtant, cela n'est pas une excuse pour ne pas les documenter.
Bien sûr, avec beaucoup de flexibilité vient une énorme liste de cas potentiels. Il ne sera pas possible de les documenter tous ici. À la place, nous espérons mettre l'accent sur certaines questions génériques qui peuvent ensuite être adaptées aux besoins personnels. Plus de réglages et d'astuces peuvent être trouvés un peu partout dans le Wiki Gentoo.
La plupart, sinon toutes ces fonctionnalités supplémentaires peuvent être facilement trouvées en explorant les pages de manuel fournies par Portage :
user $man portage
user $man make.conf
Enfin, sachez qu'il s'agit de fonctionnalités avancées qui, si elles ne fonctionnent pas correctement, peuvent rendre le débogage et le dépannage très difficiles. Assurez-vous de les mentionner lorsque vous rencontrez un bogue et ouvrez un rapport de bogue.
Variables d'environnement par paquet
Utiliser /etc/portage/env
Par défaut, les compilations de paquets utiliseront les variables d'environnement définies dans /etc/portage/make.conf, telles que CFLAGS, MAKEOPTS et plus encore. Dans certains cas cependant, il peut être avantageux de fournir différentes variables pour des paquets spécifiques. Pour ce faire, Portage prend en charge l'utilisation de /etc/portage/env et /etc/portage/package.env.
Le fichier /etc/portage/package.env contient la liste des paquets pour lesquels des variables d'environnement déviantes sont nécessaires ainsi qu'un identificateur spécifique indiquant à Portage les changements à effectuer. Le nom de l'identifiant est libre et Portage cherchera les variables dans le fichier /etc/portage/env/IDENTIFIANT.
Exemple : Utilisation du débogage pour des paquets spécifiques
A titre d'exemple, nous activons le débogage pour le paquet media-video/mplayer.
Tout d'abord, définissez les variables de débogage dans un fichier appelé /etc/portage/env/debug-cflags. Le nom est arbitrairement choisi, mais reflète bien sûr la raison de la déviation pour rendre plus évident par la suite pourquoi une déviation a été mise en place.
root #mkdir /etc/portage/env/etc/portage/env/debug-cflagsVariables spécifiques de débogageCFLAGS="-O2 -ggdb -pipe"
FEATURES="${FEATURES} nostrip"
Ensuite, nous marquons le paquet media-video/mplayer pour utiliser ce contenu :
/etc/portage/package.envUtiliser debug-cflags pour le paquet mplayermedia-video/mplayer debug-cflags
Accroches dans le processus emerge
Utiliser /etc/portage/bashrc et fichiers associés
Quand Portage travaille avec des ebuilds, il utilise un environnement bash dans lequel il appelle les différentes fonctions de compilation (comme src_prepare, src_configure, pkg_postinst, etc. ). Mais Portage permet également aux utilisateurs de configurer un environnement bash spécifique.
L'avantage d'utiliser un environnement bash spécifique est qu'il permet aux utilisateurs de s'accrocher au processus emerge lors de chaque étape qu'il effectue. Cela peut être fait pour chaque emerge (via /etc/portage/bashrc) ou en utilisant des environnements par paquet (via /etc/portage/env comme indiqué plus haut).
Portage calls so-called phase hook functions if they are defined in /etc/portage/bashrc. These functions follow the naming convention pre_phase_name and post_phase_name. For example, Portage will call the post_pkg_postinst hook just after calling the pkg_postinst phase function.
Pour s'accrocher au processus, l'environnement bash peut écouter les variables EBUILD_PHASE, CATEGORY ainsi que les variables toujours disponibles lors du développement d'ebuild (comme P, PF, ...). En fonction des valeurs de ces variables, des étapes/fonctions supplémentaires peuvent être exécutées.
Exemple : Mise à jour de la base de données de fichiers
Dans cet exemple, nous utiliserons /etc/portage/bashrc pour appeler certaines applications de base de données de fichiers afin de garantir que leurs bases de données sont à jour avec le système. Les applications utilisées dans l'exemple sont aide (un outil de détection d'intrusion) et updatedb (à utiliser avec mlocate), mais elles sont utilisées comme exemples. Ne considérez pas cela comme un guide pour AIDE !
Pour utiliser /etc/portage/bashrc dans ce cas, nous devons nous « accrocher » (hook) dans les fonctions postrm (après suppression des fichiers) et postinst ( après l'installation des fichiers), car c'est à ce moment que les fichiers ont été modifiés sur le système de fichiers.
/etc/portage/bashrcS'accrocher dans les phases postinst et postrmif [ "${EBUILD_PHASE}" == "postinst" ] || [ "${EBUILD_PHASE}" == "postrm" ];
then
echo ":: Calling aide --update to update its database"
aide --update
echo ":: Calling updatedb to update its database"
updatedb
fi
post_pkg_postinst() { my_database_update; } post_pkg_postrm() { my_database_update; } }}
Exécuter des tâches après --sync
Utiliser l'emplacement /etc/portage/postsync.d
Jusqu'à présent, nous avons parlé de l'accroche dans les processus ebuild. Cependant, Portage a aussi une autre fonction importante : mettre à jour le dépôt Gentoo. Pour exécuter des tâches après la mise à jour du dépôt Gentoo, placez un script dans /etc/portage/postsync.d et assurez-vous qu'il soit marqué comme étant exécutable.
Exemple : Exécuter eix-update
Si eix-sync n'a pas été utilisé pour mettre à jour l'arbre, il est toujours possible de mettre à jour la base de données eix après avoir lancé emerge --sync (ou emerge-webrsync) en plaçant un lien symbolique vers /usr/bin/eix appelé eix-update dans /etc/portage/postsync.d.
root #ln -s /usr/bin/eix /etc/portage/postsync.d/eix-updateSi un nom différent est choisi, alors il doit exister un script qui appelle /usr/bin/eix-update à la place. L’exécutable eix regarde comment il a été appelé pour savoir quelle fonction il doit exécuter. Si un lien symbolique a été créé pour eix mais n'est pas appelé eix-update, cela ne fonctionnera pas correctement.
Remplacer les paramètres de profil
Utiliser /etc/portage/profile
Par défaut, Gentoo utilise les paramètres contenus dans le profil pointé par /etc/portage/make.profile (lien symbolique vers le bon répertoire de profil). Ces profils définissent à la fois les paramètres spécifiques et les paramètres hérités des autres profils (via leur fichier parent).
En utilisant /etc/portage/profile, les utilisateurs peuvent remplacer les paramètres de profil tels que les paquets (les paquets considérés comme faisant partie de l'ensemble du système), les options de la variables USE forcées, et plus encore.
Exemple : Ajouter nfs-utils à l'ensemble system
Lorsque vous utilisez un système de fichiers basé sur NFS pour des systèmes de fichiers plutôt critiques, il peut être nécessaire de marquer net-fs/nfs-utils comme un paquet système, ce qui obligera Portage à avertir fortement les administrateurs si jamais une tentative est faite pour le désinstaller.
Pour ce faire, nous ajoutons le paquet à /etc/portage/profile/packages, précédé d'un * :
/etc/portage/profile/packagesMarquer nfs-utils comme un paquet système*net-fs/nfs-utils
Appliquer des correctifs non standards
Patching source code using user patches in /etc/portage/patches/
User patches provide a way to apply patches to package source code when sources are extracted before installation. This can be useful for applying upstream patches to unresolved bugs, or simply for local customizations.
Patches need to be dropped into /etc/portage/patches/. They will automatically be applied during package installation.
Patches can be dropped into any of the following directories:
- /etc/portage/patches/${CATEGORY}/${P}/ e.g. /etc/portage/patches/dev-lang/python-3.3.5-r1/
- /etc/portage/patches/${CATEGORY}/${PN}/ e.g. /etc/portage/patches/dev-lang/python-3.4.2/
- /etc/portage/patches/${CATEGORY}/${P}-${PR}/ e.g. /etc/portage/patches/dev-lang/python-3.3.5-r0/
Exemple : Appliquer des correctifs à Firefox
Le paquet www-client/firefox est l'un de ceux qui appellent déjà epatch_user dans l'ebuild, il n'est donc pas nécessaire de surcharger quoi que ce soit.
Si pour une raison quelconque (par exemple parce qu'un développeur a fourni un correctif et a demandé de vérifier s'il corrige le bogue signalé), il est nécessaire de patcher Firefox, il suffit de placer le correctif dans /etc/portage/patches/www-client/firefox (il est probablement préférable d'utiliser le nom complet et la version pour que le correctif n'interfère pas avec les versions ultérieures) et de recompiler Firefox.