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, )
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 .
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 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 sur votre miroir préféré.
extra contient tous les paquets qui ne rentrent pas dans core. Exemple : 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 choses encore.
community
Ce dépôt peut être trouvé dans .../community/os/ sur votre miroir préféré.
community contient des paquets qui ont été adoptés par des utilisateurs de confiance, souvent à partir du Arch User Repository. Certains de ces paquets peuvent éventuellement faire la transition vers les dépôts core ou extra si les développeurs les considèrent comme cruciaux pour la distribution.
multilib
Ce dépôt peut être trouvé dans 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, , etc).
Lorsque le dépôt multilib est activé, les bibliothèques compatibles 32 bits sont situées sous .
Activer le dépôt multilib
Pour activer le dépôt multilib, décommentez la section dans :
Ensuite, mettez à jour le système et installez les paquets multilib souhaités.
{Lancez pour lister tous les paquets du dépôt multilib. Les noms des paquets de bibliothèques 32 bits commencent par .}}
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 le groupe .
Commentez la section dans :
Ensuite, mettez à jour le système.
Dépôts de test
L'objectif du 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. Cependant, tous les paquets destinés au dépôt " core " doivent d'abord passer par " testing ". Les paquets qui peuvent affecter de nombreux paquets (comme ou python) doivent également être testés. Testing est aussi généralement utilisé pour les grands ensembles de paquets tels que GNOME et KDE.
testing
Ce dépôt peut être trouvé dans sur votre miroir préféré.
testing contient les paquets qui sont candidats aux dépôts core ou extra.
Les nouveaux paquets vont dans testing si :
- Ils sont destinés au dépôt core. Tout ce qui est dans core doit passer par testing.
- Ils sont censés casser quelque chose lors de la mise à jour et doivent être testés en premier.
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 .
community-testing
Ce dépôt est similaire au dépôt testing, mais pour les paquets qui sont candidats au dépôt community.
multilib-testing
Ce dépôt est similaire au dépôt 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 testing.
Pour l'activer, ajoutez les lignes suivantes à :
[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 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 à :
[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 .
- Effectuer un pour "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 testing ou vers les dépôts 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ù les 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 maintiennent désormais le dépôt [community]. Les utilisateurs de confiance restent un groupe distinct des développeurs d'Arch Linux, et il n'y a pas beaucoup de communication entre eux. Toutefois, les paquets les plus populaires vont encore de [community] vers [extra] de temps à autre. AUR permet à de simples utilisateurs d'envoyer des PKGBUILDs pour les partager avec d'autres s'ils le veulent. Ces paquets ne sont pas officiellement pris en charge, et AUR est parfois cité comme le dépôt [unsupported]. Puisqu'il n'y a pas de paquets binaires, [unsupported] n'est pas vraiment un dépôt. Les TU peuvent déplacer les paquets depuis [unsupported] vers [community] s'ils le désirent, que ce soit parce que le paquet est populaire ou parce qu'ils sont intéressés pour le maintenir.
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 [testing], et ce n'est qu'après plusieurs signatures d'autres développeurs 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.