Dépôt ebuild

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Ebuild repository and the translation is 100% complete.


Resources

Un dépôt ebuild est une structure de fichiers pouvant fournir des paquets pour l'installation sur un système Gentoo. Les dépôts ebuild contiennent des ebuilds, des eclasses et d'autres types de fichiers de métadonnées descriptives qui fournissent à Portage des paquets, des articles d'actualités, des cibles de profil, etc.

Le dépôt ebuild de Gentoo est le dépôt ebuild principal et officiel de Gentoo Linux - il contient toutes les informations nécessaires pour construire et installer chacun des paquets qui constituent Gentoo. Des dépôts ebuild supplémentaires, comme GURU, peuvent être configurés avec Portage pour fournir encore plus de paquets.

Portage installera par défaut la dernière version disponible d'un paquet à partir de n'importe quel dépôt ebuild configuré. Si la dernière version disponible est fournie par plusieurs dépôts ebuild, il sera choisi selon un ordre de priorité déterminé - d'où le nom familier overlay (ndt: surcouche).

Les administrateurs des systèmes Gentoo peuvent configurer des dépôts ebuild supplémentaires pour Portage en utilisant les utilitaires et les méthodes décrits ci-dessous.

Le dépôt ebuild Gentoo

Le dépôt ebuild Gentoo est le dépôt d'ebuilds principal pour un système Linux Gentoo, et c'est de là que viennent tous les paquets par défaut. Il est maintenu sur le serveur gitweb.gentoo.org et est synchronisé sur les machines locales (dans /var/db/repos/gentoo) afin d'être disponible pour Portage.

Le dépôt ebuild Gentoo contient des fichiers ebuild qui indiquent à Portage comment construire et installer chaque paquet. Les ebuilds sont accompagnés de métadonnées, d'informations sur les dépendances et de tout ce qui est nécessaire au bon fonctionnement d'un paquet.

Les métadonnées fournissent le nom du paquet, sa version, l'endroit où obtenir les sources, les drapeaux USE disponibles, la licence, le site web, etc. Les informations sur les dépendances dans les ebuilds permettent à Portage de récupérer tous les autres paquets nécessaires à la construction et à l'exécution d'un paquet qui doit être installé - ni plus, ni moins. Les dépendances sont très granulaires dans Gentoo, elles varient même en fonction des drapeaux USE sélectionnés, pour une sélectivité ultime. Plus important encore, les ebuilds contiennent les informations nécessaires pour configurer, construire (compiler), installer et tester chaque paquet - généralement à partir du code source d'un projet.

En plus des ebuilds, le dépôt ebuild Gentoo contient les profils officiels qui définissent l'état par défaut des drapeaux USE, les valeurs par défaut de la plupart des variables trouvées dans /etc/portage/make.conf, l'ensemble des paquets système, etc.

Le dépôt ebuild Gentoo est également l'endroit où sont publiés les articles d'actualité (ndt: news), c'est pourquoi tout nouvel article d'actualité (ndt: news) sera mis en évidence après une synchronisation du dépôt ebuild Gentoo.

Le dépôt ebuild Gentoo et ses ebuilds sont maintenus par les développeurs de Gentoo et d'autres membres de la communauté.

Remarque
Le dépôt ebuild de Gentoo sera parfois appelé par des noms plus courts, ou même familiers, tels que le dépôt Gentoo, le repo Gentoo, ::gentoo, gentoo.git, ou occasionnellement juste le "repo". Il est aussi historiquement et communément connu au sein de la communauté Gentoo comme l'arbre de Portage, l'arbre rsync, ou parfois simplement "l'arbre".
Conseil
GURU est un dépôt ebuild officiel maintenu en collaboration par les utilisateurs de Gentoo et avec l'aide de quelques développeurs de Gentoo. Il est complémentaire du dépôt ebuild de Gentoo et les mainteneurs s'efforcent de maintenir un niveau de qualité raisonnable pour les paquets fournis. Il existe également une liste de dépôts ebuild publics enregistrés sur repos.gentoo.org.

D'où viennent les dépôts ebuild ?

Parce qu'un dépôt ebuild est simplement une structure de fichiers et de répertoires, un nouveau dépôt ebuild peut être mis à la disposition de Portage simplement en copiant ces fichiers et répertoires à un emplacement connu de Portage. Les dépôts ebuild et leurs fichiers se trouvent généralement sous /var/db/repos/, mais l'emplacement des dépôts configurés pour Portage est spécifié dans /etc/portage/repos.conf. Les dépôts ebuild peuvent être configurés sur n'importe quel système de fichiers accessible, même sur un système de fichiers nfs ou SSHFS, ce qui permet de les stocker sur un réseau ou un serveur Internet.

Comme nous l'avons vu précédemment, le dépôt ebuild de Gentoo est hébergé sur gitweb.gentoo.org. Ce serveur héberge également d'autres dépôts ebuild.

En pratique, tout dépôt ebuild supplémentaire n'est généralement pas simplement copié manuellement dans un répertoire et configuré pour Portage (c'est-à-dire ajouté à /etc/portage/repos.conf). En général, de nouveaux dépôts sont mis à disposition par des tiers et, une fois configurés pour Portage, sont synchronisés par Portage. La synchronisation duplique tous les fichiers depuis un emplacement distant vers un système de fichiers local, selon la configuration.

Parce que les dépôts ebuild ne sont que des structures de fichiers, de nombreuses méthodes peuvent être utilisées pour les synchroniser, et Portage offre plusieurs possibilités. Rsync est la méthode de synchronisation par défaut, mais git est également populaire. La méthode de synchronisation est spécifiée dans /etc/portage/repos.conf lors de la configuration d'un dépôt, avec les informations nécessaires pour le récupérer.

Gestion du dépôt

Utiliser l'outil eselect repository pour ajouter, désactiver ou supprimer facilement les dépôts ebuild configurés avec Portage. Cet outil fournit également un moyen pratique de lister et d'ajouter des dépôts disponibles via leur enregistrement sur repos.gentoo.org.

Les dépôts Ebuild peuvent toujours être configurés manuellement, en éditant /etc/portage/repos.conf.

Attention !
Alors que le dépôt Gentoo ebuild est écrit ou révisé par des développeurs Gentoo, et que le dépôt GURU est supervisé par des développeurs, ce n'est pas toujours le cas pour d'autres dépôts ebuild. Il est possible que certains dépôts ebuild contiennent des logiciels vulnérables, mal conçus ou, théoriquement, même malveillants.

L'utilisateur peut également créer de nouveaux dépots ebuild à utiliser avec Portage.

La liste des dépôts ebuild actifs peut être obtenue à partir de la sortie de l'une des commandes suivantes :

user $emerge --info
user $portageq repos_config /

Installation de paquets provenant d'autres dépôts

Les paquets provenant de dépôts autres que le dépôt Gentoo peuvent être installés avec la commande emerge, comme d'habitude.

Par exemple, une fois le dépôt GURU ajouté, pour installer le paquet x11-misc/xbanish à partir de ce dépôt :

root #emerge --ask x11-misc/xbanish
These are the packages that would be merged, in order:
 
Calculating dependencies... done!
Dependency resolution took 2.96 s.
 
[ebuild   R   #] x11-misc/xbanish-1.7::guru  0 KiB
 
Total: 1 package (1 reinstall), Size of downloads: 0 KiB

Noter que le dépôt n'est pas spécifié dans la commande. Le "::guru" ajouté à l'atome du paquet dans la sortie indique le dépôt à partir duquel le paquet sera installé. Cela fonctionne car le paquet x11-misc/xbanish est présent dans le dépôt GURU, mais pas dans le dépôt Gentoo.

Si plusieurs versions d'un même paquet sont disponibles dans deux ou plusieurs dépôts ebuild différents, Portage installera la version la plus récente.

Conseil
Attention, lors des mises à jour du système, si un dépôt ebuild nouvellement ajouté fournit des versions plus récentes des paquets actuellement installés, ces paquets seront remplacés par les versions plus récentes de la superposition. Examiner si des mises à jour sont souhaitées.

Voir le masquage des dépôts ebuild activés pour éviter qu'un dépôt ebuild ne mette à jour des paquets de manière générale. Noter que le dépôt ebuild GURU évite intentionnellement de fournir des versions qui remplaceraient les paquets du dépôt ebuild de Gentoo.

Si la dernière version d'un paquet est disponible dans plus d'un dépôt ebuild, le dépôt ayant la priorité la plus élevée sera utilisé. La priorité peut être définie pour un dépôt ebuild dans le fichier /etc/portage/repos.conf. Le dépôt ebuild de Gentoo a une priorité par défaut fixée à -1000, et la priorité par défaut si aucune priorité n'est définie pour un dépôt est 0. Si plusieurs dépôts ebuild ont la même priorité (comme deux ou plus n'ayant pas de priorité définie, donc ayant la priorité 0), l'ordre est indéterminé et un paquet à installer sera sélectionné arbitrairement.

Il est possible de demander à Portage d'installer un paquet à partir d'un dépôt ebuild spécifique avec le spécificateur de version :: (qui peut être utilisé pour différentes instructions d'émergence, par exemple la désinstallation d'un paquet avec --depclean) :

root #emerge --ask category/atom::nom-dépôt

Voir la section sur la gestion des dépôts pour savoir comment lister les dépôts configurés pour portage avec leurs priorités respectives.

Synchronisation des dépôts

Les dépôts Ebuild doivent être synchronisés, de sorte que les miroirs locaux reflètent un état récent des dépôts. Cela est nécessaire pour pouvoir maintenir le système à jour et installer des logiciels récents.

Remarque
Synchroniser régulièrement avec le dépôt Gentoo et mettre à jour le système de cette manière est important pour s'assurer que toutes les dernières mises à jour de sécurité sont installées, et pour éviter que le système local ne se désynchronise trop du dépôt Gentoo, ce qui pourrait compliquer les mises à jour si le dépôt a beaucoup évolué.
Conseil
La synchronisation et la mise à jour quotidiennes ou hebdomadaires permettent à une installation Gentoo Linux de fonctionner sans problème avec les dernières mises à jour de sécurité. Attendre plus de quelques semaines pour mettre à jour peut rendre les choses un peu plus compliquées lorsque la mise à jour est tentée. Ne pas synchroniser plus d'une fois par jour, afin de ne pas surcharger les serveurs (ndt: ni être temporairement banni).
Important
Si les dépôts locaux ne sont pas très à jour, synchroniser les dépôts et mettre le système à jour avant d'installer les paquets.

La synchronisation des dépôts est effectuée avec la commande emaint sync et est configurée à travers les fichiers dans /etc/portage/repos.conf :

user $emaint --help
usage: usage: emaint [options] COMMAND
<nowiki/>
The emaint program provides an interface to system health checks
and maintenance. See the emaint(1) man page for additional
information about the following commands:
<nowiki/>
Commands:
  all            Perform all supported commands
  binhost        Scan and generate metadata indexes for binary packages.
  cleanconfmem   Check and clean the config tracker list for uninstalled packages.
  cleanresume    Discard emerge --resume merge lists
  logs           Check and clean old logs in the PORTAGE_LOGDIR.
  merges         Scan for failed merges and fix them.
  movebin        Perform package move updates for binary packages
  moveinst       Perform package move updates for installed and binary packages.
  sync           Check repos.conf settings and sync repositories.
  world          Check and fix problems in the world file.
<nowiki/>
optional arguments:
  -h, --help            show this help message and exit
  -c, --check           Check for problems (a default option for most modules)
  -f, --fix             Attempt to fix problems (a default option for most modules)
  --version             show program's version number and exit
  -C, --clean           Cleans out logs more than 7 days old (cleanlogs only) module-options: -t, -p
  -t NUM, --time NUM    (cleanlogs only): -t, --time Delete logs older than NUM of days
  -p, --pretend         (cleanlogs only): -p, --pretend Output logs that would be deleted
  -P, --purge           Removes the list of previously failed merges. WARNING: Only use this option if you plan on manually fixing them or do not want them re-installed.
  -y, --yes             (merges submodule only): Do not prompt for emerge invocations
  -r REPO, --repo REPO  (sync module only): -r, --repo Sync the specified repo
  -A, --allrepos        (sync module only): -A, --allrepos Sync all repos that have a sync-url defined
  -a, --auto            (sync module only): -a, --auto Sync auto-sync enabled repos only
  --sync-submodule {glsa,news,profiles}
                        (sync module only): Restrict sync to the specified submodule(s)

Pour synchroniser tous les dépôts pour lesquels auto-sync=true est défini, exécuter emaint sync avec le commutateur --auto (-a en abrégé). C'est généralement la commande qui doit être exécutée régulièrement, avant les mises à jour du système et l'installation de paquets (elle est équivalente à l'ancienne commande emerge --sync) :

root #emaint sync --auto

Pour synchroniser le dépôt foo (indépendamment du paramètre de synchronisation automatique pour foo) :

root #emaint sync --repo foo

Pour synchroniser tous les dépôts avec un sync-type et une sync-url valides définis (en ignorant les paramètres auto-sync) :

root #emaint sync --allrepos
Attention !
Pour tout dépôt qui ne doit pas être synchronisé lors de l'exécution de emaint sync --auto, définir obligatoirement auto-sync = no dans le fichier approprié dans /etc/portage/repos.conf, car la valeur par défaut est auto-sync = true.
Remarque
La commande emerge --sync est désormais uniquement une commande de compatibilité. Le contrôle principal de toutes les opérations de synchronisation a été transféré d'emerge à emaint, et emerge --sync appelle maintenant simplement le module de synchronisation d'emaint avec l'option --auto. Cela effectue une synchronisation uniquement avec les dépôts pour lesquels le paramètre auto-sync est défini sur yes ou true. Si l'option auto-sync n'est pas définie ou est absente pour les dépôts configurés, alors emerge --sync peut ne synchroniser aucun dépôt.
Conseil
L'outil emerge-webrsync peut être utilisé pour télécharger et installer le snapshot quotidien de rsync du dépôt Gentoo, pour aider avec les restrictions du pare-feu, ou pour accélérer la première synchronisation, par exemple.

Voir man emaint pour des informations sur l'utilisation des commandes de synchronisation de Portage. Voir l'article Portage project sync sur la migration vers le nouveau système de synchronisation modulaire à partir de la version 2.2.16 de Portage, il contient des informations importantes, notamment pour les utilisateurs de eix-sync, esync -l, et emerge --sync .

Bonnes pratiques

Génération du cache

Lorsque de grands dépôts ebuild sont installés, Portage peut mettre un temps très long pour réaliser des opérations telles que la résolution des dépendances. Ceci est dû au fait, qu'en général, les dépôts ebuild ne possèdent pas de cache des méta-données.

Générer un cache de méta-données local en exécutant la commande emerge --regen après synchronisation de vos dépôts ebuild.

root #emaint sync --allrepos
root #( ulimit -n 4096 && emerge --regen )

Rester vigilant, la commande emerge --regen prend beaucoup de temps, et n'est pas recommandée pour les utilisateurs de rsync ; puisque rsync met à jour les caches en utilisant ceux des serveurs (et la plupart des utilisateurs de portage sont utilisateurs de rsync). Si rsync est utilisé, choisir simplement emaint (ou eix-sync) pour reconstruire le cache. Normalement, seul les utilisateurs de très gros dépôts alternatifs devraient utiliser emerge --regen .

Masquage des dépôts ebuild activés

Lors de l'utilisation de grands référentiels d'ebuild ou de ceux contenant du code inconnu/de faible qualité, la meilleure pratique consiste à masquer l'ensemble du référentiel d'ebuild et à n'accepter que des ebuilds spécifiques au cas par cas. Par exemple, pour une superposition nommée "depot-foobar" :

FILE /etc/portage/package.maskMasquer tous les paquets d'un dépôt ebuild
*/*::depot-foobar

Ajouter ensuite le(s) paquet(s) spécifique(s) à partir de la superposition depot-foobar afin qu'il(s) soi(en)t visible(s) par Portage pour l'installation :

FILE /etc/portage/package.unmaskDémasquer un paquet donné dans un dépôt ebuild
categorie-foo/bar::depot-foobar

Après le démasquage ci-dessus, le paquet nommé "categorie-foo/bar" devrait être disponible et aucun des autres paquets du dépôt "depot-foobar" ne le sera.

Voir aussi

Ressources externes