Gentoo Linux hppa 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.
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 :
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) :
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 :
PORTAGE_ELOG_MAILSUBJECT="Le paquet \${PACKAGE} a été installé sur \${HOST} avec quelques messages"
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 to300
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 hppa.
# The following value is set by default, and does _not_ need explicitly defined.
ACCEPT_KEYWORDS="hppa"
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
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.
ACCEPT_KEYWORDS="~hppa"
Par exemple, pour sélectionner la branche testing pour l'architecture hppa, 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 :
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 :
=app-office/gnumeric-1.2.13
Paquets masqués
package.unmask
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 :
=net-mail/hotwayd-0.8
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.13, ajoutez la ligne suivante dans package.mask :
>sys-kernel/gentoo-sources-6.6.13
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.
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 :
PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes"
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) :
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é :
[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.13 a été installé manuellement, ajoutez la ligne suivante à /etc/portage/profile/package.provided :
sys-kernel/gentoo-sources-6.6.13
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
CFLAGS="-O2 -ggdb -pipe"
FEATURES="${FEATURES} nostrip"
Ensuite, nous marquons le paquet media-video/mplayer pour utiliser ce contenu :
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).
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.
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
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
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 *
:
*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.
Warning: Display title "Gentoo Linux hppa Handbook: Working with Portage" overrides earlier display title "Handbook:HPPA/Full/Portage/fr".