Official repositories (Français)
Un dépôt de logiciels est un emplacement de stockage à partir duquel les paquets logiciels sont récupérés pour être installés.
Les dépôts officiels d'Arch Linux contiennent des logiciels essentiels et populaires, facilement accessibles via pacman. Ils sont maintenus par des mainteneurs de paquets.
Les paquets dans les dépôts officiels sont constamment mis à jour : quand un paquet est mis à jour, son ancienne version est supprimée du dépôt. Il n'y a pas de version majeure d'Arch : chaque paquet est mis à jour au fur et à mesure que de nouvelles versions deviennent disponibles à partir des sources en amont. Chaque dépôt est toujours cohérent, c'est-à-dire que les paquets qu'il héberge ont toujours des versions réciproquement compatibles.
Dépôts stables
core
Ce dépôt peut être trouvé dans .../core/os/ sur votre miroir préféré.
core contient des paquets pour :
- le démarrage d'Arch Linux
- la connexion à Internet
- la construction de paquets (en)
- la gestion et la réparation des systèmes de fichiers pris en charge
- le processus de configuration du système (par exemple, openssh)
ainsi que les dépendances des éléments ci-dessus (pas nécessairement les dépendances nécessaires à la compilation) et le méta-paquet base.
core a des exigences de qualité assez strictes. Les développeurs/utilisateurs doivent approuver les mises à jour avant que les mises à jour de paquets ne soient acceptées. Pour les paquets peu utilisés, une diffusion raisonnable est suffisante : informer les gens de la mise à jour, demander des signatures, maintenir en core-testing jusqu'à une semaine selon la gravité du changement, l'absence de rapports de bogue en suspens, ainsi que la signature implicite du responsable du paquet.
extra
Ce dépôt peut être trouvé dans .../extra/os/ sur votre miroir préféré.
extra contient tous les paquets qui ne rentrent pas dans core. Ce dépôt est maintenu conjointement par les utilisateurs de confiance et les développeurs d'Arch. Exemples : Xorg, les gestionnaires de fenêtres, les navigateurs web, les lecteurs multimédia, les outils pour travailler avec des langages comme Python et Ruby, et bien d'autres encore.
multilib
Ce dépôt peut être trouvé dans .../multilib/os/ sur votre miroir préféré.
multilib contient des logiciels et des bibliothèques 32 bits qui peuvent être utilisés pour exécuter et construire des applications 32 bits sur des installations 64 bits (par exemple wine, steam, etc).
Lorsque le dépôt multilib est activé, les bibliothèques compatibles 32 bits sont situées sous /usr/lib32/.
Activer le dépôt multilib
Pour activer le dépôt multilib, décommentez la section [multilib] dans /etc/pacman.conf :
/etc/pacman.conf
[multilib] Include = /etc/pacman.d/mirrorlist
Ensuite, mettez à jour le système et installez les paquets multilib souhaités.
pacman -Sl multilib pour lister tous les paquets du dépôt multilib. Les noms des paquets de bibliothèques 32 bits commencent par lib32-.Désactiver le dépôt multilib
Exécutez la commande suivante pour supprimer tous les paquets qui ont été installés à partir de multilib :
# pacman -R $(comm -12 <(pacman -Qq | sort) <(pacman -Slq multilib | sort))
Si vous avez des conflits avec gcc-libs, réinstallez le paquet gcc-libs et les dépendances du paquet base-devel (Voir pacman (Français)/Tips and tricks (Français)#Dépendances d'un paquet).
Commentez la section [multilib] dans /etc/pacman.conf :
/etc/pacman.conf
#[multilib] #Include = /etc/pacman.d/mirrorlist
Ensuite, mettez à jour le système.
Dépôts de test
L'objectif des dépôt *-testing est de fournir une zone de transit pour les paquets avant leur acceptation dans les dépôts principaux. Les mainteneurs de paquets (et les utilisateurs en général) peuvent alors accéder à ces paquets de test pour s'assurer qu'il n'y a pas de problèmes pour intégrer le nouveau paquet. Une fois qu'un paquet a été testé et qu'aucune erreur n'a été trouvée, le paquet peut alors être déplacé vers les dépôts principaux.
Tous les paquets n'ont pas besoin de passer par ce processus de test. Les nouveaux paquets vont dans un dépôt de test si :
- Ils sont destinés au dépôt core. Tout ce qui se trouve dans core doit passer par core-testing.
- On s'attend à ce qu'ils cassent quelque chose lors de la mise à jour et doivent être testés en premier.
- Ils affectent de nombreux paquets (comme perl ou python).
Les dépôts de test sont aussi généralement utilisé pour les nouvelles versions de grands ensembles de paquets tels que GNOME et KDE.
- Soyez prudent lorsque vous activez les dépôts de test. Votre système peut se casser après avoir effectué une mise à jour. Seuls les utilisateurs expérimentés qui savent comment gérer les pannes potentielles du système devraient l'utiliser.
- Si vous activez core-testing, vous devez également activer extra-testing et vice versa. Si vous activez tout autre dépôt de test listé dans les sous-sections suivantes, vous devez également activer à la fois core-testing et extra-testing.
core-testing
Ce dépôt peut être trouvé dans .../core-testing/os/ sur votre miroir préféré.
core-testing contient les paquets qui sont candidats au dépôt core.
core-testing est le seul dépôt qui peut avoir des collisions de noms avec les autres dépôts officiels. S'il est activé, il doit être le premier dépôt listé dans votre fichier /etc/pacman.conf.
extra-testing
Ce dépôt est similaire au dépôt core-testing, mais pour les paquets qui sont candidats au dépôt extra.
multilib-testing
Ce dépôt est similaire au dépôt core-testing, mais pour les paquets candidats au dépôt multilib.
gnome-unstable
Ce dépôt contient des paquets de test pour la prochaine version stable ou candidate à la version stable de l'environnement de bureau GNOME, avant qu'ils ne soient déplacés vers le dépôt principal extra-testing.
Pour l'activer, ajoutez les lignes suivantes à /etc/pacman.conf :
/etc/pacman.conf
[gnome-unstable] Inclure = /etc/pacman.d/mirrorlist
L'entrée gnome-unstable doit être la première dans la liste des dépôts (i.e., au-dessus de l'entrée extra-testing).
Veuillez signaler les bogues liés à l'empaquetage dans notre bug tracker, tandis que tout autre problème doit être signalé en amont au Gitlab de GNOME.
kde-unstable
Ce dépôt contient la dernière version beta ou Release Candidate de KDE Plasma et Applications. Plasma et Applications.
Pour l'activer, ajoutez les lignes suivantes à /etc/pacman.conf :
/etc/pacman.conf
[kde-unstable] Include = /etc/pacman.d/mirrorlist
L'entrée kde-unstable doit être la première dans la liste des dépôts (i.e., au-dessus de l'entrée testing).
Assurez-vous de signaler les bugs si vous rencontrez des problèmes.
Désactivation des dépôts de test
Si vous avez activé les dépôts de tests, mais que vous avez décidé plus tard de les désactiver, vous devez :
- Les supprimer (les commenter) de
/etc/pacman.conf. - Effectuer un
pacman -Syuupour "annuler" vos mises à jour depuis ces dépôts.
Le deuxième élément est facultatif, mais gardez-le à l'esprit si vous remarquez des problèmes.
Dépôts pour paquets en construction
Ce dépôt contient des paquets cassés et est utilisé uniquement par les développeurs lors de la reconstruction de nombreux paquets à la fois. Afin de reconstruire des paquets qui dépendent, par exemple, d'une nouvelle bibliothèque partagée, la bibliothèque partagée elle-même doit d'abord être construite et téléchargée vers les dépôts de transit pour être mise à la disposition des autres développeurs. Dès que tous les paquets dépendants sont reconstruits, le groupe de paquets est alors déplacé vers les dépôts de test ou principaux, selon ce qui est le plus approprié.
Consultez l'annonce de l'introduction de ces dépôts pour plus de détails historiques.
Historique
La plupart des divisions de dépôts sont liées à des raisons historiques. À l'origine, Arch Linux était utilisée par peu d'utilisateurs, il n'y avait qu'un dépôt appelé official (core à présent). À cette époque, official contenait les applications préférées de Judd Vinet. Il n'était alors conçu que pour contenir un seul programme de chaque type: un environnement de bureau, un navigateur web, etc.
À cette époque, certains utilisateurs n'aimaient pas la sélection d'applications de Judd, et puisque ABS est si facile à utiliser, ils créèrent leurs propres paquets. Ces paquets allèrent dans un dépôt nommé unofficial, et furent maintenus par d'autres développeurs que Judd. Puis finalement, comme les deux dépôts étaient aussi bien maintenus par les développeurs, les noms official et unofficial cessèrent de correspondre à leurs statuts. Ils furent donc renommés en current et extra aux alentours de la version 0.5 d'Arch Linux.
Peu après la sortie de la version 2007.8.1, current fut renommé core afin d'éviter les confusions sur le contenu du dépôt. Les deux dépôts sont à présent plus ou moins égaux aux yeux des développeurs et de la communauté, mais core a quelques différences. La distinction principale est que les paquets utilisés pour les CDs d'installation et par les instantanés proviennent uniquement de core. Ce dépôt offre un système GNU/Linux complet, bien que cela puisse ne pas être le système GNU/Linux que vous désirez.
Aux alentours de 0.5 et 0.6, il apparut que les développeurs ne voulaient plus maintenir un certain nombre de paquets. Un des développeurs (Xentac) créa les "Trusted User Repositories" : les dépôts des utilisateurs de confiance, qui y mettaient les paquets qu'ils voulaient bien maintenir. Il y avait également un dépôt staging où pouvaient être promus les paquets vers les dépôts officiels par un des développeurs d'Arch Linux. Mais outre cela, les développeurs et les utilisateurs de confiance étaient plus ou moins distincts.
Cela fonctionna durant un temps, jusqu'au moment où certains utilisateurs de confiance se lassèrent de leurs paquets, et que de simples utilisateurs manifestèrent le souhait de partager leurs propres paquets. Ceci mena au développement d'AUR. Les TUs (Trusted Users, utilisateurs de confiance) furent rassemblés en un groupe plus resserré, et maintiennaient désormais le dépôt community. Les utilisateurs de confiance restaient un groupe distinct des développeurs d'Arch Linux, et il n'y avait pas beaucoup de communication entre eux. Toutefois, les paquets les plus populaires allaient encore de community vers extra de temps à autre. AUR permet à tous les utilisateurs d'envoyer des PKGBUILDs pour les partager avec d'autres s'ils le veulent.
Après qu'un noyau dans core a cassé de nombreux systèmes utilisateurs, la "core signoff policy" a été introduite. Depuis lors, toutes les mises à jour de paquets pour core doivent d'abord passer par un dépôt core-testing, et ce n'est qu'après plusieurs signatures d'autres développeurs ou des personnes de l'équipe de test d'Arch qu'elles sont autorisées. Au fil du temps, il a été remarqué que plusieurs paquets core étaient peu utilisés, et les signatures des utilisateurs ou même le manque de rapports de bogues sont devenus des critères informels pour accepter ces paquets.
Fin 2009/début 2010, avec l'arrivée de certains nouveaux systèmes de fichiers et le désir de les prendre en charge lors de l'installation, ainsi que la prise de conscience que le terme core n'a jamais été clairement défini (juste "des paquets importants, triés sur le volet par les développeurs"), le dépôt a reçu une description plus précise.
En 2023, après des années de travail, la distribution a migré sa gestion des paquets vers git et, dans le même temps, est passée à une nouvelle disposition des dépôts. Dans la nouvelle disposition, extra contient tous les paquets qui étaient auparavant dans community et les dépôts de test ont été divisés de testing à core-testing et extra-testing, community-testing a été entièrement supprimé. À partir de ce moment, les utilisateurs de confiance ont également été en mesure de publier de nouveaux paquets vers extra.