Jump to content

# Official repositories (Français)

6 languages

- English
- Español
- 日本語
- Português
- Русский
- 中文（简体）

From ArchWiki
É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 :

1. Les supprimer (les commenter) de `/etc/pacman.conf`.
2. 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.

Categories:

- Package management (Français)
- About Arch (Français)

Hidden category:

- Pages or sections flagged with Template:Translateme (Français)