Gentoo Linux ppc64 Handbook: Working with Portage

Les fichiers de Portage

Directives de configuration

Portage est livré avec une configuration par défaut située dans /usr/share/portage/config/make.globals. Toute la configuration de Portage est gérée par des variables. Les variables influant sur Portage, ainsi que leur signification, seront détaillées plus tard.

Étant donné que de nombreuses directives de configuration diffèrent suivant les architectures, Portage possède également des fichiers de configuration par défaut qui font partie du profil du système. Ce profil est pointé par le lien symbolique /etc/portage/make.profile. Les configurations de Portage sont définies dans les fichiers make.defaults du profil et de tous les profils parents. Nous expliquerons plus en détail les profils et le répertoire /etc/portage/make.profile plus tard.

Lorsque vous modifiez une variable de configuration, ne modifiez pas /usr/share/portage/config/make.globals ou make.defaults. Plutôt, utilisez /etc/portage/make.conf qui a la priorité sur les fichiers précédents. Pour plus d'informations, lire le fichier /usr/share/portage/config/make.conf.example. Comme son nom l'indique, ceci n'est qu'un exemple de fichier - Portage ne lit pas dans ce fichier.

Il est également possible de définir une variable de configuration Portage en tant que variable d'environnement, mais nous ne le recommandons pas.

Information spécifique au profil

Nous avons déjà rencontré le répertoire /etc/portage/make.profile. En fait, ce n'est pas exactement un répertoire mais un lien symbolique vers un profil, par défaut celui de /var/db/repos/gentoo/profiles/ bien que l'on puisse créer ses propres profils ailleurs et y pointer. Le profil indiqué par ce lien symbolique est le profil auquel le système adhère.

Un profil contient des informations spécifiques à l'architecture pour Portage, telles qu'une liste de paquets appartenant au système correspondant à ce profil, une liste de paquets qui ne fonctionnent pas (ou qui sont masqués) pour ce profil, etc.

Configuration spécifique à l'utilisateur

Lorsque le comportement de Portage doit être modifié en ce qui concerne l'installation d'un logiciel, alors le bon jeu de fichiers dans /etc/portage/ devra être changé. Il est fortement recommandé d'utiliser les fichiers dans /etc/portage/ et fortement déconseillé de surcharger le comportement par l'utilisation des variables d'environnement !

Dans /etc/portage/ les utilisateurs peuvent créer les fichiers suivants :

• package.mask qui liste les paquets que Portage ne devrait jamais essayer d'installer
• package.unmask qui liste les paquets que Portage devrait pouvoir installer même si les développeurs Gentoo découragent fortement les utilisateurs de le faire
• package.accept_keywords qui liste les paquets que Portage devrait pouvoir installer même si le paquet n'a pas encore été confirmé comme stable pour le système ou l'architecture
• package.use qui répertorie les options de la variable USE à utiliser pour certains paquets sans que le système entier utilise ces options de la variable USE

Ceux-ci n'ont pas être des fichiers ; ils peuvent également être des répertoires contenant un fichier par paquet. Vous trouverez plus d'informations sur le répertoire /etc/portage/ et une liste complète des fichiers pouvant être créés dans la page de manuel de Portage :

user $man portage

Changer l'emplacement des fichiers et répertoires de Portage

Les fichiers de configuration mentionnés précédemment ne peuvent pas être stockés ailleurs - Portage recherchera toujours ces fichiers de configuration à ces emplacements précis. Cependant, Portage utilise de nombreux autres emplacements à des fins diverses : répertoire de compilation, stockage du code source, emplacement du dépôt Gentoo, ...

Tous ces objectifs ont des emplacements par défaut bien connus mais peuvent être modifiés selon les goûts personnels via /etc/portage/make.conf. Le reste de ce chapitre explique les emplacements spéciaux que Portage utilise et comment modifier leur emplacement sur le système de fichiers.

Ce document n'est pas destiné à être utilisé comme une référence. Pour obtenir une couverture complète, veuillez consulter les pages de manuel de Portage et de make.conf :

user $man portage

user $man make.conf

Stocker des fichiers

Le dépôt ebuild de Gentoo

L'emplacement par défaut du dépôt ebuild de Gentoo est /var/db/repos/gentoo. Cela est défini par le fichier repos.conf situè à l'emplacement /usr/share/portage/config/repos.conf. Pour modifier la valeur par défaut, copiez ce fichier dans /etc/portage/repos.conf/gentoo.conf et modifiez le paramètre location. Lorsque vous stockez le dépôt ebuild e Gentoo ailleurs (en modifiant cette variable), n'oubliez pas de changer le lien symbolique /etc/portage/make.profile en conséquence.

Après avoir modifié le paramètre location dans /etc/portage/repos.conf/gentoo.conf, il est recommandé de modifier les variables suivantes dans /etc/portage/make.conf car elles ne remarqueront pas la modification du paramètre location : PKGDIR, DISTDIR, et RPMDIR. Cela est dû à la façon dont Portage gère les variables.

Exécutables pré-compilés

Bien que Portage n'utilise pas d'exécutables pré-compilés par défaut, il en possède un support étendu. Lorsque vous demandez à Portage de travailler avec des paquets pré-compilés, il les recherchera dans /var/cache/binpkgs. Cet emplacement est défini par la variable PKGDIR.

Code source

Le code source des programmes est stocké par défaut dans /var/cache/distfiles. Cet emplacement est défini par la variable DISTDIR.

Base de données Portage

Portage enregistre l'état du système (quels paquets sont installés, quels fichiers appartiennent à quel paquet, ...) dans /var/db/pkg.

Attention !
Ne pas modifier manuellement les fichiers sur l'état du système ! Cela pourrait casser les connaissances de Portage sur le système.

Le cache de Portage

Le cache de Portage (avec les temps de modification, les virtuals, les informations de l'arbre des dépendances, ...) est stocké dans /var/cache/edb. Cet emplacement est en réalité un cache : les utilisateurs peuvent le nettoyer s'ils n'exécutent aucune application liée à Portage en ce moment.

Compiler des programmes

Fichiers temporaires de Portage

Les fichiers temporaires de Portage sont stockés dans /var/tmp/ par défaut. Cela est défini par la variable PORTAGE_TMPDIR.

Répertoire de compilation

Portage crée des répertoires de compilation spécifiques pour chaque paquet qu'il émerge à l'intérieur de /var/tmp/portage/. Cet emplacement est défini par la variable PORTAGE_TMPDIR avec portage/ ajouté en suffixe.

Emplacement du système de fichiers courant

Par défaut, Portage installe tous les fichiers sur le système de fichiers courant (/), mais cela peut être changé en définissant la variable d'environnement ROOT. Cela est utile lors de la création de nouvelles images de construction.

Fonctions de journalisation

Journalisations Ebuild

Portage peut créer des fichiers journaux par ebuild, mais uniquement lorsque la variable PORT_LOGDIR est définie sur un emplacement accessible en écriture par Portage (via l'utilisateur Portage). Par défaut, cette variable n'est pas définie. Si PORT_LOGDIR n'est pas définie, il n'y aura pas de journaux d'installation avec le système de journalisation actuel, bien que les utilisateurs puissent recevoir des journaux du nouveau support elog.

Si PORT_LOGDIR n'est pas défini et que elog est utilisé, alors les journaux d'installation et tous les autres journaux sauvegardés par elog seront rendus disponibles, comme expliqué ci-dessous.

Portage offre un contrôle précis de la journalisation grâce à l'utilisation de elog :

• PORTAGE_ELOG_CLASSES : C'est ici que les utilisateurs peuvent définir les types de messages à journaliser. Cela peut être n'importe quelle combinaison des termes einfo, warn, error, log, et qa, séparés par un espace.
  • info : Enregistre les messages « einfo » affichés par un ebuild
  • warn : Enregistre les messages « ewarn » affichés par un ebuild
  • error : Enregistre les messages « eerror » affichés par un ebuild
  • log : Enregistre les messages « elog » trouvés dans certains ebuilds
  • qa : Enregistre les messages « QA Notice » (Avis d'assurance qualité) affichés par un ebuild

• PORTAGE_ELOG_SYSTEM : Cela sélectionne le(s) module(s) pour traiter les événements du journal. Si elle est vide, la journalisation est désactivée. Toutes les combinaisons des termes save, custom, syslog, mail, save_summary, et mail_summary, séparés par un espace, peuvent être utilisées, . Au moins un module doit être utilisé pour utiliser elog.
  • save : enregistre un journal par paquet dans $PORT_LOGDIR/elog, ou /var/log/portage/elog si $PORT_LOGDIR n'est pas défini.
  • custom : passe tous les messages à une commande définie par l'utilisateur dans $PORTAGE_ELOG_COMMAND ; cela sera discuté plus tard.
  • syslog : envoie tous les messages au système de journalisation du système.
  • mail : transmet tous les messages à un serveur mail défini par l'utilisateur dans $PORTAGE_ELOG_MAILURI ; cela sera discuté plus tard. Les fonctionnalités de messagerie d'elog requièrent >=portage-2.1.1.
  • save_summary : similaire à save, mais il fusionne tous les messages dans $PORT_LOGDIR/elog/summary.log, ou /var/log/portage/elog/summary.log si $PORT_LOGDIR n'est pas défini.
  • mail_summary : similaire à mail, mais il envoie tous les messages dans un seul courrier quand emerge se termine.

• PORTAGE_ELOG_COMMAND : Cela est uniquement utilisé lorsque le module personnalisé est activé. Les utilisateurs peuvent spécifier une commande pour traiter les événements journaux. Notez que la commande peut utiliser deux variables: ${PACKAGE} est le nom et la version du paquet, tandis que ${LOGFILE} est le chemin absolu du fichier journal. Par exemple :

CODE Exemple de définition de PORTAGE_ELOG_COMMAND

PORTAGE_ELOG_COMMAND="/path/to/logger -p '\${PACKAGE}' -f '\${LOGFILE}'"

• PORTAGE_ELOG_MAILURI : Cela contient des paramètres pour le module de messagerie tels que l'adresse, l'utilisateur, le mot de passe, le serveur de messagerie et le numéro de port. Le paramètre par défaut est « root@localhost localhost ». Voici un exemple d'un serveur SMTP qui nécessite une authentification par nom d'utilisateur et mot de passe sur un port particulier (le port par défaut est le port 25) :

CODE Exemple de définition de PORTAGE_ELOG_MAILURI

PORTAGE_ELOG_MAILURI="user@some.domain username:password@smtp.some.domain:995"

• PORTAGE_ELOG_MAILFROM : Permet à l'utilisateur de définir l'adresse d’expédition des courriels de journaux ; Si non définie, est égale à « Portage » par défaut.

• PORTAGE_ELOG_MAILSUBJECT : Permet à l'utilisateur de créer un objet pour les courriels. Notez qu'il peut utiliser deux variables : ${PACKAGE} affichera le nom et la version du paquet, alors que ${HOST} est le nom de domaine complet de l'hôte sur lequel Portage s'exécute. Par exemple :

CODE Exemple de définition de PORTAGE_ELOG_MAILSUBJECT

PORTAGE_ELOG_MAILSUBJECT="Le paquet \${PACKAGE} a été installé sur \${HOST} avec quelques messages"

Important
Les utilisateurs qui ont utilisé enotice avec Portage-2.0.* doivent supprimer complètement enotice, car il est incompatible avec elog.

Configuration de Portage

Comme indiqué précédemment, Portage est configurable via de nombreuses variables qui doivent être définies dans /etc/portage/make.conf ou l'un des sous-répertoires de /etc/portage/. Reportez-vous aux pages de manuel de make.conf et de portage pour obtenir des informations plus complètes :

user $man make.conf

user $man portage

Options spécifiques de compilation

Les options de configure et du compilateur

Lorsque Portage compile des applications, il transmet le contenu des variables suivantes au compilateur et au script configure :

CFLAGS et CXXFLAGS

Définissent les options de compilation souhaitées pour la compilation des langages C et C ++.

CHOST

Définit les informations de l'hôte de compilation pour le script de configuration de l'application.

MAKEOPTS

Passée à la commande make et est généralement utilisée pour définir la quantité de parallélisme utilisée lors de la compilation. Plus d'informations sur les options make peuvent être trouvées dans la page de manuel de make.

La variable USE est également utilisée lors de la configuration et des compilations mais a été expliquée en détail dans les chapitres précédents.

Options d'installation

Lorsque Portage a installé une version plus récente d'un certain logiciel, il supprimera les fichiers obsolètes de l'ancienne version du système. Portage accorde à l'utilisateur un délai de 5 secondes avant la suppression de l'ancienne version. Ces 5 secondes sont définies par la variable CLEAN_DELAY.

Il est possible d'indiquer à emerge d'utiliser certaines options chaque fois qu'elle est exécutée en définissant EMERGE_DEFAULT_OPTS. Certaines options utiles seraient --ask, --verbose, --tree, et ainsi de suite.

Protection du fichier de configuration

Emplacements protégés de Portage

Portage écrase les fichiers fournis par les nouvelles versions d'un logiciel si les fichiers ne sont pas stockés dans un emplacement protégé. Ces emplacements protégés sont définis par la variable CONFIG_PROTECT et sont généralement des emplacements de fichiers de configuration. La répertoires sont délimités par des espaces.

A file that would be written in such a protected location is renamed and the user is warned about the presence of a newer version of the (presumable) configuration file.

To find out about the current CONFIG_PROTECT setting, use the emerge --info output:

user $emerge --info | grep 'CONFIG_PROTECT='

More information about Portage's configuration file protection is available in the CONFIGURATION FILES section of the emerge manpage:

user $man emerge

Exclure des répertoires

To 'unprotect' certain subdirectories of protected locations users can use the CONFIG_PROTECT_MASK variable.

Options de téléchargement

Emplacements des serveurs

When the requested information or data is not available on the system, Portage will retrieve it from the Internet. The server locations for the various information and data channels are defined by the following variables:

GENTOO_MIRRORS

Defines a list of server locations which contain source code (distfiles).

PORTAGE_BINHOST

Defines a particular server location containing prebuilt packages for the system.

A third setting involves the location of the rsync server which users use to update their local Gentoo repository. This is defined in the /etc/portage/repos.conf file (or a file inside that directory if it is defined as a directory):

sync-type

Defines the type of server and defaults to rsync.

sync-uri

Defines a particular server which Portage uses to fetch the Gentoo repository.

The GENTOO_MIRRORS, sync-type, and sync-uri variables can be set automatically through the mirrorselect application. Of course, app-portage/mirrorselect needs to be installed first before it can be used. For more information, see mirrorselect's online help:

root #mirrorselect --help

If the environment requires the use of a proxy server, then the http_proxy, ftp_proxy, and RSYNC_PROXY variables can be declared.

Commandes de téléchargement

When Portage needs to fetch source code, it uses wget by default. This can be changed through the FETCHCOMMAND variable.

Portage is able to resume partially downloaded source code. It uses wget by default, but this can be altered through the RESUMECOMMAND variable.

Make sure that the FETCHCOMMAND and RESUMECOMMAND store the source code in the correct location. Inside the variables the \${URI} and \${DISTDIR} variables can be used to point to the source code location and distfiles location respectively.

It is also possible to define protocol-specific handlers with FETCHCOMMAND_HTTP, FETCHCOMMAND_FTP, RESUMECOMMAND_HTTP, RESUMECOMMAND_FTP, and so on.

Paramètres de rsync

It is not possible to alter the rsync command used by Portage to update the Gentoo repository, but it is possible to set some variables related to the rsync command:

PORTAGE_RSYNC_OPTS

Sets a number of default variables used during sync, each space-separated. These shouldn't be changed unless you know exactly what you're doing. Note that certain absolutely required options will always be used even if PORTAGE_RSYNC_OPTS is empty.

PORTAGE_RSYNC_EXTRA_OPTS

Used to set additional options when syncing. Each option should be space separated:

--timeout=<number>

This defines the number of seconds an rsync connection can idle before rsync sees the connection as timed-out. This variable defaults to 180 but dialup users or individuals with slow computers might want to set this to 300 or higher.

--exclude-from=/etc/portage/rsync_excludes

This points to a file listing the packages and/or categories rsync should ignore during the update process. In this case, it points to /etc/portage/rsync_excludes.

--quiet

Reduces output to the screen.

--verbose

Prints a complete filelist.

--progress

Displays a progress meter for each file.

PORTAGE_RSYNC_RETRIES

Defines how many times rsync should try connecting to the mirror pointed to by the SYNC variable before bailing out. This variable defaults to 3.

For more information on these options and others, please read man rsync.

Configuration de Gentoo

Choix de la branche

It is possible to change the default branch with the ACCEPT_KEYWORDS variable. It defaults to the architecture's stable branch. More information on Gentoo's branches can be found in the next chapter.

Fonctionnalités de Portage

It is possible to activate certain portage features through the FEATURES variable. The Portage features have been discussed in previous chapters.

Comportement de Portage

Gestion des ressources

With the PORTAGE_NICENESS variable users can augment or reduce the nice value Portage will use while running. The PORTAGE_NICENESS value is added to the current nice value of Portage.

For more information about nice values, see Portage niceness and the nice man page:

user $man nice

Comportement de sortie

The NOCOLOR variable, which defaults to false, defines if Portage should disable the use of colored output.

Utiliser une branche

Stable

La variable ACCEPT_KEYWORDS définit la branche logicielle à utiliser sur le système. Elle correspond par défaut à la branche logicielle stable pour l'architecture du système, par exemple ppc64.

FILE /etc/portage/make.confUsing the stable branch

# The following value is set by default, and does _not_ need explicitly defined.
ACCEPT_KEYWORDS="ppc64"

Il est recommandé de rester avec la branche stable. Cependant, si la stabilité n'est pas très importante et/ou si l'administrateur veut aider Gentoo en soumettant des rapports de bogues à https://bugs.gentoo.org, alors la branche testing peut être utilisée à la place.

Testing

Attention !
Hic sunt dracones! Running software from the testing branch may incur stability issues, imperfect package handling (for instance wrong/missing dependencies), frequent ebuild revisions (resulting in a lot of compiling) or packages that are broken in another, often unexpected, manner. System administrators who are less comfortable with Gentoo or Linux in general should avoid the testing branch. As noted previously, the Handbook recommends staying with the stable, more thoroughly tested branch.

Pour utiliser des logiciels plus récents, les utilisateurs peuvent envisager d'utiliser la branche testing à la place. Pour que Portage utilise la branche testing, ajoutez un ~ devant l'architecture.

FILE /etc/portage/make.confUtiliser la branche testing

ACCEPT_KEYWORDS="~ppc64"

Par exemple, pour sélectionner la branche testing pour l'architecture ppc64, modifiez /etc/portage/make.conf et définissez :

La branche testing est exactement ce que son nom indique, une branche de Test. Si un paquet est en test, cela signifie que les développeurs pensent qu'il est fonctionnel mais n'a pas été testé de manière approfondie. Les utilisateurs utilisant la branche testing pourraient très bien être les premiers à découvrir un bogue dans le paquet, auquel cas ils devraient déposer un rapport de bogue pour en informer les développeurs.

Lors du passage de stable à testing, les utilisateurs découvriront que beaucoup de paquets seront mis à jour. Gardez à l'esprit qu'après le passage à la branche testing, il peut être difficile de revenir à la branche stable.

Mélanger stable et testing

package.accept_keywords

Il est possible de demander à Portage d'autoriser la branche testing pour des paquets particuliers mais d'utiliser la branche stable pour le reste du système. Pour ce faire, ajoutez la catégorie et le nom du paquet dans /etc/portage/package.accept_keywords. Il est également possible de créer un répertoire (avec le même nom) et de lister le paquet dans les fichiers sous ce répertoire.

Par exemple, pour utiliser la branche testing pour gnumeric :

FILE /etc/portage/package.accept_keywordsUtiliser la branche testing uniquement pour l'application gnumeric

app-office/gnumeric

Tester des versions particulières

Pour utiliser une version de logiciel spécifique de la branche testing quand vous ne voulez pas que Portage utilise la branche testing pour les versions ultérieures, ajoutez la version dans package.accept_keywords. Dans ce cas, utilisez l'opérateur =. Il est également possible d'entrer une gamme de versions en utilisant les opérateurs <=, <, > ou >=.

Dans tous les cas, si des informations de version sont ajoutées, un opérateur doit être utilisé. Sans informations de version, un opérateur ne peut pas être utilisé.

Dans l'exemple suivant, nous demandons à Portage d'autoriser l'installation de gnumeric-1.2.13 même s'il se trouve dans la branche testing :

FILE /etc/portage/package.accept_keywordsAutoriser la sélection d'une version spécifique

=app-office/gnumeric-1.2.13

Paquets masqués

package.unmask

Important
Les développeurs Gentoo ne supportent pas le démasquage des paquets. Veuillez faire preuve de prudence lorsque vous le faites. Les demandes de support liées à package.unmask et/ou package.mask peuvent ne pas être traitées.

Quand un paquet a été masqué par les développeurs Gentoo, si malgré la raison mentionnée dans le fichier package.mask (situé par défaut dans /var/db/repos/gentoo/profiles/), un utilisateur veut utiliser ce paquet, ajoutez alors la version désirée (habituellement ce sera la même ligne que dans le fichier package.mask du profil) dans /etc/portage/package.unmask (ou dans un fichier de ce répertoire s'il s'agit d'un répertoire).

To do so, the system administrator would add the target package version (usually this will be the exact same line from the package.mask file in the profile) to the /etc/portage/package.unmask location.

Par exemple, si =net-mail/hotwayd-0.8 est masqué, il peut être démasqué en ajoutant exactement la même ligne dans le fichier package.unmask :

FILE /etc/portage/package.unmaskDémasquer une combinaison paquet/version particulière

=net-mail/hotwayd-0.8

Remarque
Si une entrée dans /var/db/repos/gentoo/profiles/package.mask contient une série de versions de paquetages, alors il est nécessaire de démasquer seulement la ou les version(s) réellement nécessaires. Veuillez lire la section précédente pour savoir comment spécifier les versions.

package.mask

Il est également possible de demander à Portage de ne pas tenir compte d'un certain paquet ou d'une version spécifique d'un paquet. Pour ce faire, masquez le package en ajoutant une ligne appropriée dans /etc/portage/package.mask (dans ce fichier ou dans un fichier de ce répertoire).

Par exemple, pour empêcher Portage d'installer des sources du noyau plus récentes que gentoo-sources-6.6.21, ajoutez la ligne suivante dans package.mask :

FILE /etc/portage/package.maskMasquer gentoo-sources ayant une version plus récent que 6.6.21

>sys-kernel/gentoo-sources-6.6.21

dispatch-conf

dispatch-conf est un outil qui facilite la fusion des fichiers ._cfg0000_<name>. Les fichiers ._cfg0000_<name> sont générés par Portage quand il veut écraser un fichier dans un répertoire protégé par la variable CONFIG_PROTECT.

Avec dispatch-conf, les utilisateurs peuvent fusionner des mises à jour de leurs fichiers de configuration tout en gardant une trace de tous les changements. dispatch-conf stocke les différences entre les fichiers de configuration en tant que correctifs ou en utilisant le système de révision RCS. Cela signifie que si quelqu'un fait une erreur lors de la mise à jour d'un fichier de configuration, l'administrateur peut à tout moment rétablir le fichier à la version précédente.

Lors de l'utilisation de dispatch-conf, les utilisateurs peuvent demander de conserver le fichier de configuration tel quel, d'utiliser le nouveau fichier de configuration, de modifier le fichier en cours ou de fusionner les modifications de manière interactive. dispatch-conf, a aussi de belles fonctionnalités supplémentaires :

• Fusionner automatiquement les mises à jour de fichiers de configuration qui contiennent uniquement des mises à jour de commentaires.
• Fusionner automatiquement les fichiers de configuration qui ne diffèrent que par la quantité d'espaces.

Editez d'abord /etc/dispatch-conf.conf et créez le répertoire référencé par la variable archive-dir. Ensuite, exécutez dispatch-conf :

root #dispatch-conf

Lors de l'exécution de dispatch-conf, chaque fichier de configuration modifié sera examiné un par un. Appuyez sur u pour mettre à jour (remplacer) le fichier de configuration actuel avec le nouveau et passer au fichier suivant. Appuyez sur z pour zapper (supprimer) le nouveau fichier de configuration et passer au fichier suivant. La touche n demandera à dispatch-conf de passer au fichier suivant. Cela peut être fait pour délayer une fusion. Une fois que tous les fichiers de configuration ont été pris en charge, dispatch-conf va quitter. A tout moment, q peut également être utilisé pour quitter l'application.

Pour plus d'informations, consultez la page de manuel dispatch-conf. Elle décrit comment fusionner de manière interactive les fichiers de configuration actuels et nouveaux, éditer de nouveaux fichiers de configuration, examiner les différences entre les fichiers, et plus encore.

user $man dispatch-conf

quickpkg

Avec quickpkg, les utilisateurs peuvent créer des archives de paquets déjà installés sur le système. Ces archives peuvent être utilisées comme paquets pré-compilés. L'exécution de quickpkg est simple : ajoutez simplement les noms des paquets à archiver.

Par exemple, pour archiver curl, orage et procps :

root #quickpkg curl orage procps

Les paquets pré-compilés seront stockés dans $PKGDIR (/var/cache/packages/ par défaut). Ces paquets sont placés dans $PKGDIR/CATEGORY.

Utiliser un sous-ensemble du dépôt Gentoo

Exclure des paquets et des catégories

Il est possible de mettre à jour sélectivement certaines catégories/paquets et d'ignorer les autres catégories/paquets. Cela peut être réalisé en demandant à rsync d'exclure les catégories/paquets lors de l'étape emerge --sync.

Attention !
In order for this method to work, manifest verification must be disabled. This will reduce the security of the repo. To disable the verification, either disable the rsync-verify USE flag on the sys-apps/portage package or set sync-rsync-verify-metamanifest=no (see man 5 portage) in the repos.conf entry of the Gentoo ebuild repository.

Définissez le nom du fichier qui contient les modèles d'exclusion dans la variable PORTAGE_RSYNC_EXTRA_OPTS dans /etc/portage/make.conf :

FILE /etc/portage/make.confDéfinition du fichier d'exclusion

PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes"

FILE /etc/portage/rsync_excludesExclure tous les jeux

games-*/*

Notez toutefois que cela peut entraîner des problèmes de dépendances, car de nouveaux paquets autorisés peuvent dépendre de nouveaux paquets exclus.

Ajouter des ebuilds non officiels

Définir un dépôt ebuild personnalisé

Manual creation

Il est possible de demander à Portage d'utiliser des ebuilds qui ne sont pas officiellement disponibles via le dépôt Gentoo. Créez un nouveau répertoire (par exemple /usr/local/portage) dans lequel seront stockés les ebuilds tiers. Utilisez la même structure que pour le dépôt officiel de Gentoo !

root #mkdir -p /var/db/repos/localrepo/{metadata,profiles}

root #chown -R portage:portage /var/db/repos/localrepo

Ensuite, choisissez un nom sensé pour le dépôt. L'exemple suivant utilise "localrepo" comme nom :

root #echo 'localrepo' > /var/db/repos/localrepo/profiles/repo_name

Then define the EAPI used for the profiles within the repository:

root #echo '8' > /var/db/repos/localrepo/profiles/eapi

Dites à Portage que le dépôt maître est le dépôt ebuild principal de Gentoo et que le dépôt local ne doit pas être synchronisé automatiquement (car il n'est pas alimenté par une source externe telle qu'un serveur rsync, un miroir git, ou tout autre type de dépôt) :

FILE /var/db/repos/localrepo/metadata/layout.conf

masters = gentoo
auto-sync = false

Enfin, activez le dépôt sur le système local en créant un fichier de configuration de dépôt dans /etc/portage/repos.conf. Cela indiquera à Portage où se trouve le dépôt local personnalisé :

FILE /etc/portage/repos.conf/localrepo.conf

[localrepo]
location = /var/db/repos/localrepo

Optional: Creating a repo using eselect repository

Alternatively, a custom ebuild repository can be quickly created using the eselect repository module (from app-eselect/eselect-repository). In the following example, substitute localrepo with a name of choice:

root #eselect repository create localrepo

Adding localrepo to /etc/portage/repos.conf/eselect-repo.conf ...
Repository <ebuild_repository_name> created and added

A bare repository named "localrepo" will be made available at /var/db/repos/localrepo.

Travailler avec plusieurs dépôts alternatifs

For those desiring to develop several ebuild repos, test packages before they hit the Gentoo repository, or who want to use unofficial ebuilds from various sources, the app-eselect/eselect-repository package also provides tooling to aid in keeping repositories up to date. See also eselect repository article.

eselect-repository

Par exemple, pour activer le dépôt alternatif hardened-development :

root #eselect repository enable hardened-development

Mettre à jour des dépôts alternatifs ajoutés avec cette méthode se fait de manière transparente avec :

root #emerge --sync

Logiciels non gérés par Portage

Utiliser Portage avec des logiciels auto-gérés

Parfois, les utilisateurs veulent configurer, installer et maintenir un logiciel individuellement sans que Portage n'automatise le processus, même si Portage peut fournir les logiciels voulus. Les cas connus sont les sources du noyau et les pilotes Nvidia. Il est possible de configurer Portage pour qu'il sache qu'un certain paquet est installé manuellement sur le système (et donc prendre en compte cette information lors du calcul des dépendances). Ce processus s'appelle injecting et est pris en charge par Portage via le fichier /etc/portage/profile/package.provided.

Par exemple, pour informer Portage que gentoo-sources-6.6.21 a été installé manuellement, ajoutez la ligne suivante à /etc/portage/profile/package.provided :

FILE /etc/portage/profile/package.providedMarquer gentoo-sources-6.6.21 comme manuellement installé

sys-kernel/gentoo-sources-6.6.21

Remarque
C'est un fichier qui utilise les versions sans l'opérateur =.

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

FILE /etc/portage/env/debug-cflagsVariables spécifiques de débogage

CFLAGS="-O2 -ggdb -pipe"
FEATURES="${FEATURES} nostrip"

Ensuite, nous marquons le paquet media-video/mplayer pour utiliser ce contenu :

FILE /etc/portage/package.envUtiliser debug-cflags pour le paquet mplayer

media-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.

FILE /etc/portage/bashrcS'accrocher dans les phases postinst et postrm

if [ "${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-update

Remarque
Si 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 * :

FILE /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.