Repositories/fr

In other languages: English (en) français (fr) 日本語 (ja) [edit]

Cette page fournit des informations sur les différents dépôts de Fedora pour les différentes versions, sur les relations qu'ils ont entre eux et sur les paquets qu'ils contiennent.

Le dépôt fedora

Le dépôt fedora existe pour toutes les versions de Fedora après qu'elles ont fourché — en anglais "Branched" — depuis Rawhide. Il apparaît pour Yum ou DNF dans le fichier fedora.repo dans le chemin du dépôt. Pour toute installation de Fedora, ce dépôt est activé par défaut et devrait ordinairement le rester.

Le dépôt de Fedora dans les versions stables

Pour les versions stables, fedora représente l'état gelé de la version. Il fait partie de l’arbre gelé qui est créé par Release Engineering lorsqu’une version est approuvée lors d’une réunion de décision appelée Go_No_Go_Meeting. Le jeu de paquets qu'il contient ne change plus à partir de ce momentt. Il représente l'état « stable » d’une version en conjonction avec le dépôt updates — dépôt des mises à jour en français.

Les dépots fedora de la version stable pour les différentes architectures primaires sont visibles dans le dossier /fedora/linux/releases/XX/Everything des miroirs (nom dans lequel XX représente la version), et peut aussi faire l’objet d’une requête auprès du gestionnaire de miroirs. Par exemple, la page https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-41&arch=x86_64 affiche les miroirs pour le dépôt fedora x86_64 de Fedora 41.

Le dépôt fedora dans les versions Branched

Dans les versions Branched — l’état du dépôt "fedora" est intermédiaire entre son état au moment où la version a fourché de Rawhide et celui de la version stable, voir la page Branched pour plus d’information — seul le dépôt fedora représente l’état « stable » de la version. Le dépôt updates pour les versions "Branched" n’est pas utilisé avant que la version ne devienne stable. Avant le Bodhi enabling point — point de validation Bodhi —, les compilations de paquets pour la version "Branched" sont envoyées directement à ce dépôt. Après le point de validation Bodhi, les compilations de paquets qui satisfont aux exigences de la Updates Policy — politique de mise à jour —, migrent du dépôt updates-testing vers ce dépôt.

Les dépôts fedora pour les différentes architectures primaires sont visibles dans le dossier /fedora/linux/development/XX des miroirs (nom dans lequel XX représente la version) et peuvent aussi faire l’objet de requêtes auprès du gestionnaire de miroirs. Par exemple, la page https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-42&arch=x86_64 affiche les dépôts de fedora x86_64 pour Fedora 42.

Le dépôt updates

Le dépôt updates — dépôt des mises à jour — existe pour les versions stables et "Branched", mais est seulement utilisé et peuplé dans les versions stables. Il est représenté pour Yum ou DNF dans le fichier fedora-updates.repo dans le chemin du dépôt. Il existe seulement dans les versions "Branched" pour éviter aux divers outils qui s’attendent à le trouver de planter. Pour toute installation de Fedora, ce dépôt est activé par défaut, et devrait ordinairement le rester.

Pour les versions stables, , updates et fedora associés représentent l’état stable courant de la version.Les compilations de paquet qui satisfont aux exigences de la politique de mise à jour migrent du dépôt the updates-testing vers ce dépôt. Cette différence d’avec "Branched" résulte de la nécessité d’avoir une représentation de l’état "gelé" initial d'une version stable.

The stable release updates repositories for the various primary architectures can be found in the /fedora/linux/updates/XX directory on the mirrors (where XX is the release), and can also be queried from MirrorManager. For instance, https://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f41&arch=x86_64 will return mirrors for the x86_64 updates repository for Fedora 41.

Les dépôts "updates" de la version stable pour les différentes architectures primaires sont visibles dans le dossier /fedora/linux/updates/XX des miroirs (nom dans lequel XX représente la version), et peuvent aussi faire l’objet de requêtes auprès du gestionnaire de miroirs. Par exemple, la page https://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f41&arch=x86_64 affiche les miroirs du dépôt updates x86_64 de Fedora 41.

Le dépôt updates-testing

Le dépôt updates-testing — test des mises à jour — existe pour les versions "Branched" après le Bodhi enabling point, et pour les versions stables. Il est représenté pour Yum ou DNF dans le fichier fedora-updates-testing.repo dans le chemin du dépôt. Pour les deux, c’est un emplacement "transitoire" dans lequel les compilations de paquet sont testées avant d’être marquées comme 'stable' ( et de là, déplacées vers le dépôt , fedora pour les versions "Branched", ou le dépôt updates pour les versions stables).

On fait parfois référence à ces compilations sous le nom "updates candidates", et elles sont passées en revue avec l’outil Bodhi de retour d’expérience des mises à jour, en suivant les directives d’utilisation des retours d’expérience des mises à jour.

La politique des mises à jour définit les règles à suivre pour marquer une compilation "update candidate" comme 'stable'. La page QA updates-testing donne quelques informations aux testeurs sur la manière d’utiliser ce dépôt. La page directives sur la mise à jour des paquets donne des informations aux empaqueteurs sur la manière de soumettre des compilations à 'updates-testing et à stable.

Le dépôt updates-testing est activé par défaut pour les versions "Branched", mais désactivé par défaut pour les versions stables. Le basculement est fait aux environs du gel final pour chacune des versions. Les testeurs qui passent de "Branched" à stable, sont susceptible de rencontrer des erreurs en exécutant les mises à jour autour de cette date, à cause de conflits de dépendances entre paquets déjà installés à partir du désormais désactivé dépôt "updates-testing". L’exécution de la commande dnf distro-sync (ou de la commande yum) ou la ré-activation du dépôt updates-testing atténuent tous deux le problème. Il appartient à l’utilisateur de décider s'il désire continuer à utiliser le dépôt updates-testing après la parution de la version stable ou pas.

Les dépôts updates-testing des deux versions "Branched" et stable, sont visibles dans le dossier /fedora/linux/updates/testing/XX des miroirs (chemin dans lequel XX est le numéro de version), et peuvent également faire l’objet de requêtes auprès du gestionnaire de miroirs. Par exemple, la page https://mirrors.fedoraproject.org/mirrorlist?repo=updates-testing-f41&arch=x86_64 affiche les miroirs du dépôt x86_64 updates-testing pour Fedora 41.

Le dépôt rawhide

Dans Rawhide — la version roulante de Fedora, de laquelle une version est fourchée avant de terminer en version stable —, rawhide est le seul dépôt. C'est là que tous les paquets compilés sont envoyés. Il est représenté pour Yum ou DNF dans le fichier fedora-rawhide.repo dans le chemin du dépôt. Il devrait être activé dans tout système exécutant "Rawhide" ; pour n'importe quel autre système il devrait être désactivé.

Les dépots rawhide des différentes architectures primaires sont visibles dans le dossier /fedora/linux/development/rawhide des miroirs, et peuvent également faire l’objet de requêtes auprès du gestionnaire de miroirs. Par exemple, la page https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-rawhide&arch=x86_64 affiche les miroirs du dépôt x86_64 fedora de "Rawhide".

stable n’est pas un dépôt

Il n’est pas rare de voir des références au dépôt 'stable'. Il s’agit là d’un abus de language. "stable" est plutôt un état que l'on peut considérer comme existant à la fois pour les versions Branched après la validation Bodhi et stables. Il est constitué de compilations de paquets qui faisaient partie de Rawhide au moment où elles ont fourché, de compilation de paquets envoyés directement au dépôt fedora de la version "Branched" entre le moment où elle a fourché et le "point de validation Bodhi", ainsi que de compilations de paquets qui ont satisfait aux exigences de la politique de mise à jour, et qui ont migré depuis updates-testing après le "point de validation Bodhi".

Pour les versions "Branched", l’état stable est seulement représenté par le contenu du dépôt fedora (et, mais ça se discute, de celui du dépôt bleed , mais c’est un cas marginal).

Pour les versions stables, l’état stable est représenté par le contenu du dépôt fedora, combiné à celui du dépôt updates .

stable est aussi l’état dans lequel un paquet peut être considéré être — ou un attribut qu'on peut considérer lui appartenant — lorsqu'il est "pushed stable" (poussé stable) ou "tagged stable" (marqué stable) et existe, ou existera bientôt, dans un dépôt "stable" d’une version — quel que soit le dépôt litéral (voir ci-dessus).

Dépôts / arbres d' installation et de produit

Les dépôts auxquels il est fait référence ci-dessus ne sont ni associés à un « produit » Fedora.next spécifique, ni ne font partie d’un arbre installable — un arbre contenant les fichiers nécessaires utilisés comme dépôt de base par Anaconda, l’installateur de Fedora. Des dépôts spécialisés existent pour cela.

Pour les versions "Fedora.next" — Fedora 21 et postérieures —, il n’y a, depuis septembre 2014, aucun arbre installable qui ne soit associé à un produit spécifique. Les arbres installables pour différents produits sont disponibles sous /fedora/linux/releases/XX/ dans les miroirs pour les versions stables, et sous /fedora/linux/releases/test/ pour les jalons de pré-version des "Branched". Ils peuvent également faire l’objet de requêtes auprès du gestionnaire de miroirs. Par exemple, la page https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-server-42&arch=x86_64 affiche les miroirs des dépôts d’’installation courante x86_64 pour Fedora 42 Server.

Ces dépôts sont gelés — de nouveaux paquets n’y sont plus poussés — et sont créés à différents points du cycle de vie d’une version de Fedora. Un nouvel arbre d’installation — qui contient un dépôt — est compilé pour plusieurs produits pour chaque test compose or release candidate build — composition de test ou compilation de candidat à version —, et les arbres pour les version alpha et béta sont rendus disponibles dans les miroirs dans le dossier /releases/test — voir ci-dessus. Ils contiennent un sous-ensemble du jeu complet de paquets qui est considéré comme définissant chacun des produits — voir comps pour les détails techniques sur ce point.

Les arbres de produit pour la version GA (Finale) sont rendus disponibles dans l’arbre /releases dans les miroirs.

À un point donné du cycle de version, la requête auprès du gestionnaire de miroirs d’un dépôt de produit peut rediriger vers un arbre test compose / release candidate, un arbre de jalon de pré-version, ou l’arbre de la version finale.

Ces dépôts ne sont ordinairement ni utilisés ni activés par défaut sur les systèmes installés, car dans ce but, ils sont redondants avec un des trois dépôts primaires décrits ci-dessus. Cependant, on peut utiliser un dépôt de produit à la place du dépôt fedora pour garder un système se limitant au jeu de paquets du produit. Ils sont représentés pour Yum ou DNF dans le fichier fedora-(product).repo dans le chemin du dépôt, qui peut très bien ne pas être installé sur de nombreux systèmes.

Other repositories

There are other repositories that fulfil various niche purposes, which are documented here for the sake of providing a comprehensive reference. They should not usually be significant to the vast majority of Fedora users. None of these repositories is represented in a packaged repository file, enabled by default, or should usually be used in a Fedora installation.

The bleed repository

The bleed repository exists for a single purpose: during Milestone freezes, it contains packages that have been granted 'freeze exceptions' via the QA:SOP_blocker_bug_process or QA:SOP_freeze_exception_bug_process, and which are desired to be included in the next test compose or release candidate build, but have not yet reached stable state and hence been moved to the fedora repository. In other words, it contains packages explicitly required in TC/RC compose requests.

The bleed repository can be found here, but again, is not usually of interest to the vast majority of Fedora users. The packages it contains are always also available from the build system, Koji, and usually from the updates-testing repository.

The latest repositories

The latest repositories contain packages for various build 'tags' as they arrive in the Koji build system. They are not mashed, a process which principally handles multilib, and using them can cause various problems, in addition to overloading Fedora's development servers. It is almost always a better idea to cherry-pick new builds from Koji or Bodhi via their web interfaces or command line tools.

Repositories FAQ

Why is updates only used after the stable release?

As described above, updates for both Branched pre-releases and final, 'stable' releases go through the updates-testing process before being moved to a stable repository. Before the final release, they are placed in the fedora repository. After release, they are placed in updates.

The reason for the difference is that we want to have a record of the exact 'state' of a given Fedora stable release. That is, at the time a Fedora release is declared to be done at a Go No Go Meeting, we consider the state of the release at that time to be the canonical definition of that release, and we wish to preserve a record of that state. For a stable release, the tree containing the fedora repository is that record, and the fedora repository it contains is the canonical record of the precise frozen package set that formed the main part of that stable release.

Since we wish to maintain this frozen state for the fedora repository, we cannot place updates directly into it. The necessity for the updates repository therefore becomes obvious - we need a place to put updates to stable releases that is outside the frozen state of the release.

Before a stable release occurs, this mechanism is not necessary. Before the release is declared to be done, there is no frozen state of the release: effectively, the whole Branched development process is working towards what will become the frozen state of the release, so of course package builds for the Branched release land directly in the fedora repository.

Why is updates-testing enabled by default in pre-releases?

While Branched development releases and stable releases both use an updates-testing repository together with the Bodhi update feedback system to stage packages before they reach the release's stable state, it is enabled by default in Branched, but not in stable releases.

The reason is that the purpose of the updates-testing system is somewhat different in each case. For stable releases, the system's goal is to prevent broken updates reaching the general Fedora user population. In most cases, Fedora systems are expected to have the updates-testing repository disabled. Some QA testers then enable the repository on testing systems to try out the updates and provide feedback. The testers perform the job of making sure the updates are OK before they reach the general user population.

When it comes to a Branched pre-release, the expectation is that anyone who installs it wants to help test it: we effectively consider anyone running a Branched release to be a tester. The function of updates-testing is different in this case. There is not a 'general user population' of Branched users who run with updates-testing disabled, and are protected from problematic updates by the group of update testers. Instead, updates-testing in Branched serves other important functions.

The main purpose is to insulate image builds from potentially problematic changes. Branched images - nightly images, and the Alpha, Beta and GA (Final) milestone builds and their test compose and release candidate builds - are built from the stable packages, that is, only those in the fedora repository, not those in updates-testing. In this sense, updates-testing protects not a set of users, but a set of builds, from potentially destabilizing changes. Especially when we are building an Alpha, Beta or GA release, we need to be able to reduce the amount of change in the package set between composes in order to produce an image of high quality. The updates-testing mechanism allows for that: during Milestone freezes, new builds can be sent to updates-testing, but cannot move from there to stable (fedora) without special circumstances (see the blocker and freeze exception processes). In this way, we can work on release images while not preventing packagers from sending out builds.

For this and other less important functions, we need as much feedback as possible, so it makes sense to have all pre-release testers have updates-testing enabled by default, and encourage them to provide feedback through Bodhi.