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 est représenté et décrit, à la fois pour Yum ou DNF, dans le fichier fedora.repo dans le dossier des dépôts dont le chemin est /etc/yumrepos.d/. 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 moment. 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é et décrit, à la fois pour Yum ou DNF, dans le fichier fedora-updates.repo dans le dossier des dépôts dont le chemien est /etc/yum.repos.d/. 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é et décrit, à la fois pour Yum ou DNF, dans le fichier fedora-updates-testing.repo dans le dossiers des dépôts dont le chemin est /etc/yum.repos.d'. 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 susceptibles 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é et décrit, à la fois pour Yum ou DNF, dans le fichier fedora-rawhide.repo dans le dossier des dépôts dont le chemin est /etc/yum.repos.d. 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 versions 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 et décrits, à la fois pour Yum ou DNF, dans le fichier fedora-(product).repo dans le dossier des dépôts dont le chemin est /etc/yum.repos.d, et peuvent très bien ne pas être installés sur de nombreux systèmes.
Autres dépôts
Il existe d’autres dépôts qui satisfont des besoins de niche variés, et qui sont documentés ici afin de fournir une référence complète. Généralement, ils ne devraient pas avoir d’intérêt pour la grande majorité des utilisateurs de Fedora. Aucun de ces dépôts n’est représenté dans un fichier de dépôt empaqueté, ni activé par défaut, ni ne devrait être utilisé au cours d’une installation de Fedora.
Le dépôt bleed
Le dépôt "bleed" n’existe que dans un seul but : durant les gels de jalon, il contient les paquets qui ont obtenu la marque "freeze exception" (exception au gel) via le QA:SOP_blocker_bug_process (processus de blocage des anomalies) ou le QA:SOP_freeze_exception_bug_process (processus de traitement des anomalies marquées "freeze exception"), et que l’on souhaite inclure dans la prochaine "test compose" ou compilation de "release candidate", mais qui n’ont pas encore un état "stable" et qui de là, ont migré vers le dépôt fedora. En d’autres mots, il contient les paquets explicitement requis dans une TC/RC compose requests (requête de composition).
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. Le dépôt "bleed" est disponible [http://kojipkgs.fedoraproject.org/mash/bleed/ ici, mais disons-le une fois de plus, ne présente généralement aucun intérêt pour la grande majorité des utilisateurs de Fedora. Les paquets qu’il contient sont toujours disponibles dans le système de compilation, Koji, et en général, dans le dépôt updates-testing (test des mises à jour).
Les dépôts latest
Les repositories| dépôts "latest" (derniers) contiennent des paquets pour différents "tags" (étiquettes) de compilation lorsqu’ils arrivet dans le système de compilation Koji. Ils ne sont pas mashed — un processus qui s’occupe principalement de multilib —, et leur utilisation peut générer des problèmes variés, sans parler de la surcharge des serveurs du développement de Fedora. C’est en général une meilleure idée de faire son marché aux nouvelles compilations de Koji ou Bodhi via leur interface Web ou leurs outils en ligne de commande.
FAQ sur les dépôts
Pourquoi updates n’est-il utilisé qu’après la version stable ?
Comme il est expliqué ci-dessus, updates, à la fois pour les pré-versions 'Branched' et les versions finales 'stable', les compilations des mises à jour doivent satisfaire aux exigences du processus updates-testing (test des mises à jour) avant d’être déplacées vers un dépôt stable. Avant la version finale, elles sont placées dans le dépôt fedora. Après la version finale, elles sont placées dans le dépôt updates.
La raison qui explique cette différence est que nous désirons conserver un enregistrement de l’état exact d’une version stable de Fedora. Cela veut dire que, au moment où la version finale est déclarée prête lors d’une Go No Go Meeting (réunion on y va, on y va pas), nous considérons que nous avons là la définition canonique de cette version, et nous voulons en garder l’enregistrement. Pour une version stable, l’arbre contenant le dépôt "fedora" est cet enregistrement, et le dépôt qu’il contient est l’enregistrement canonique du jeu gelé de paquets qui constitue la partie principale de cette version stable.
Comme nous voulons maintenir cet état 'gelé' pour le dépôt fedora, nous ne pouvons y placer directement les mises à jour. La nécessité du dépot updates apparaît donc comme évidente — nous avons besoin d’un endroit pour y placer les mises à jour de la version stable qui s’écartent de l’état gelé de cette version.
Avant que n’apparaisse une version stable, ce mécanisme n’est pas nécessaire. Avant qu’une version ne soit déclarée finale, il n’y a pas d’état gelé de la version : en effet, le processus complet de développement d’une version Branched, s’emploie à converger vers ce qui deviendra l’état gelé de la version, aussi, bien sûr, les compilations de paquets pour la version Branched atterrissent directement dans le dépôt fedora.
Pourquoi updates-testing est-il activé par défaut dans les pré-versions ?
Bien que les versions de développement Branched et les versions stables utilisent toutes deux un dépôt updates-testing, en association avec le système Bodhi de prise en compte de l’expérience sur les mises à jour, pour présenter à la validation les paquets avant qu’ils n’accèdent à l’état stable de la version, celui-ci est activé par défaut dans les versions Branched, mais pas dans les versions stables.
La raison en est que l’objectif du système associé à updates-testing est quelque peu différent dans chacun des cas. Pour les versions stables, le but du système est d’empêcher que des mises à jour défaillantes n’atteignent l’utilisateur standard de Fedora. Dans la plupart des cas, on s’attend à ce que sur les systèmes Fedora, le dépôt updates-testing soit désactivé. Quelques testeurs QA peuvent alors activer ce dépôt sur leur système de test pour essayer les mises à jour et rapporter leur expérience. Les testeurs ont pour rôle de garantir que les mises à jour sont valides avant qu’elles n’atteignent l’utilisateur standard.
Quant aux pré-versions Branched, nous estimons que celui qui les installe le fait dans un but de test. La fonction de updates-testing est différente dans ce cas. Il n’y a pas d’utilisateurs standard qui utilise une version Branched avec updates-testing désactivé, et qui soit protégé des mises à jour problématiques par le groupe de testeurs des mises à jour. Au lieu de cela, updates-testing dans les versions Branched remplit d’autres importantes fonctions.
L’objectif principal est d’isoler les compilations d’images des modifications potentiellement problématiques. Les images Branched — les images de chaque nuit, ainsi que les compilations de jalon Alpha, Béta et GA (finale), et leurs test compose and release candidate builds (compilation de compositions de test et de versions candidates) — sont compilées à partir des paquets stables, c.-à-d., seulement ceux qui se trouvent dans le dépôt fedora, pas ceux qui sont dans le dépôt updates-testing. En ce sens, updates-testing ne protège pas un ensemble d’utilisateurs, mais un ensemble de compilations, de changements potentiellement déstabilisateurs. En particulier, lorsque nous compilons une version Alpha, Béta ou GA, nous devons être capables de réduire la quantité de modifications dans le jeu de paquets entre compositions pour produire une image de haute qualité. Le mécanisme updates-testing nous le permet : durant les [[Milestone freezes|gels de jalon], de nouvelles compilations peuvent être envoyées à updates-testing, mais ne peuvent, sauf circonstances spéciales — voir les processus blocker(blocage) et freeze exception (exception au gel) — migrer de là vers stable (fedora). De cette façon, nous pouvons travailler sur des images de version sans pour autant empêcher les empaqueteurs d’émettre de nouvelles compilations.
Pour cela, et pour d’autres fonctions moins importantes, nous avons besoin d’un maximum de retour d’expérience, c’est pourquoi, cela fait sens d’avoir updates-testing activé pour tous les testeurs de pré-versions en les encourageant à assurer ce retour d’expérience via Bodhi.