Official repositories (Français)

État de la traduction:
Cet article est la version francophone de
Official repositories
. Date de la dernière traduction: 2023-05-21. Vous pouvez aider à synchroniser la traduction s'il y a eu des
changements
dans la version anglaise.
Related articles
Arch Build System (Français)
Arch User Repository (Français)
makepkg (Français)
Mirrors (Français)
pacman (Français)
PKGBUILD (Français)
Unofficial user repositories
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.
Astuce
Pour créer un dépôt local avec les paquets de
core
(ou d'autres dépôts) sans connexion Internet, voir
Pacman (Français)/Tips and tricks (Français)#Installation de paquets depuis un CD/DVD ou clef USB
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.
Astuce
Lancez
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
.
Note
Les dépôts de test ne sont pas destiné aux "dernières des dernières" versions de paquet. Une partie de son but est de contenir les mises à jour de paquets qui ont le potentiel de casser le système, soit en faisant partie de l'ensemble de paquets de
core
, soit en étant critiques d'une autre manière. En tant que tels, les utilisateurs des dép sont fortement encouragés à s'abonner à la
mailing list arch-dev-public
, à regarder le
forum du dépôt testing (en)
, et à
signaler tous les bugs
. Vous devriez également envisager de rejoindre l'équipe
Arch Testing Team
.
Attention
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 -Syuu
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
Attention
Ne pas activer les dépôts
staging
pour quelque raison que ce soit. Votre système se brisera inévitablement après une mise à jour. Ce dépôt est uniquement destiné à être utilisé par les développeurs backend.
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.
Cet article ou section a besoin d'être
traduit(e)
.
Notes:
Note de traduction: il manque l'histoire entre 2010 et 2023, voir
Official repositories#Historical background
. (Discuss in
Talk:Official repositories (Français)#
)
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
.