Repositorios Fedora
Esta página explica los diversos repositorios Fedora que existen para las diferentes Versiones de Fedora, las relaciones entre ellos y los paquetes que contienen.
El repositorio fedora
El repositorio fedora existe para todos los lanzamientos Fedora después de que pasan a Branched desde Rawhide. Está representado para DNF en el archivo fedora.repo en la ruta del repositorio. Para cualquier instalación Fedora este repositorio será habilitado de forma predeterminada y debe normalmente mantenerse así.
El repositorio fedora en los lanzamientos estables
Para los lanzamientos estables, fedora representa el estado de lanzamiento congelado. Es una parte del árbol congelado que es creado por Release Engineering (Ingeniería de Lanzamiento) cuando un lanzamiento es aprobado en un Go/No-Go Meeting (Reunión Va/No Va). El conjunto de paquetes no contiene nunca cambios después de ese momento. Representa el estado stable de un lanzamiento estable junto con el repositorio updates.
Los repositorios de lanzamiento estable fedora para las diversas arquitecturas principales se pueden encontrar en el directorio /fedora/linux/releases/XX/Everything en los espejos (donde XX es el lanzamiento) y se puede consultar también desde MirrorManager. Por ejemplo, https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-40&arch=x86_64 devolverá los espejos del repositorio x86_64 fedora para el lanzamiento 40.
El repositorio fedora en versiones Branched
En las versiones Branched – el estado en el que se encuentra una versión entre la ramificación de Rawhide y la versión estable, vea más detalles en Branched – el repositorio fedora por si solo representa el estado estable de la versión. El repositorio updates (actualizaciones) para las versiones Branched no se usa hasta que llegan a ser estable. Antes del punto de habilitación Bodhi, los paquetes construidos para la versión Branched son enviados directamente a este repositorio. Después del punto de habilitación Bodhi, los paquetes construidos que pasen la Política de Actualizaciones se mueven del repositorio updates-testing a este repositorio.
Los repositorios_fedora_ de Branched para las diversas arquitecturas principales se pueden encontrar en el directorio /fedora/linux/development/XX en los espejos (donde XX es la versión) y también se pueden consultar desde MirrorManager. Por ejemplo, https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-41&arch=x86_64 devolverá los espejos para el repositorio x86_64 fedora de la versión 41.
El repositorio updates
El repositorio updates existe para las versiones Branched y estable, pero solo se completa y utiliza para versiones estables. Se representa para DNF en el archivo fedora-updates.repo en la ruta del repositorio. Existe en las versiones Branched solamente para evitar que diversas herramientas que esperan su existencia se rompan. Para alguna instalación Fedora, este repositorio será habilitado de forma predeterminada y normalmente permanecerá así.
Para las versiones estables, updates junto con updates representan el estado estable actual de la versión. Los paquetes construidos que pasen la Política de Actualizaciones se mueven del repositorio updates-testing a este repositorio. Esta diferencia con Branched es un resultado de la necesidad de mantener la representación precia del estado inicial 'frozen' de una versión estable.
Los repositorios de updates de las versiones estables para las diversas arquitecturas principales se pueden encontrar en el directorio /fedora/linux/updates/XX en los espejos (donde XX es la versión) y se pueden consultar también desde el MirrorManager (Administrador de Espejos). Por ejemplo, https://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f40&arch=x86_64 devolverá los espejos para el repositorio updates de la versión 40.
El repositorio updates-testing
El repositorio updates-testing existe para las versiones Branched después del punto de habilitación Bodhi y para las versiones estables. Esta representado para DNF en el archivo fedora-updates-testing.repo en la ruta de repositorios. Para ambos, es una ubicación 'preparada' donde se prueban las nuevas compilaciones de paquetes antes de ser marcadas como 'estable' (y por lo tanto llevadas al repositorio fedora o al repositorio updates, respectivamente).
A estas compilaciones nos referimos algunas veces como update candidates y son revisadas con la herramienta de comentarios de actualización Bodhi, de acuerdo a las directrices de comentarios de actualización.
La Política de Actualizaciones define las reglas para marcar las actualizaciones candidatas como stable. La página de Garantía de Calidad pruebas de actualizaciones proporciona alguna información a los evaluadores sobre la utilización de este repositorio. La Guía de Actualización de Paquetes proporciona información a los empaquetadores sobre el envío de compilaciones a updates-testing y a stable.
El repositorio updates-testing está habilitado de forma predeterminada para las versiones Branched, pero deshabilitado de forma predeterminada para las versiones estables. El cambio se realiza alrededor del momento de la Congelación Final de cada versión. Los evaluadores que pasan de Branched a estable pueden encontrar errores ejecutando las actualizaciones en este momento, causados por fallos en las dependencias entre paquetes ya instalados desde el repositorio updates-testing ahora deshabilitado. Ejecutando dnf distro-sync o volviendo a habilitar el repositorio updates-testing normalmente se soluciona el problema; depende del usuario si desea continuar usando el repositorio updates-testing después de la versión estable o no.
Los repositorios updates-testing para las versiones tanto Branched como estable se pueden encontrar en el directorio /fedora/linux/updates/testing/XX en los espejos (donde XX es la versión) y pueden ser consultados desde MirrorManager. Por ejemplo, https://mirrors.fedoraproject.org/mirrorlist?repo=updates-testing-f40&arch=x86_64 devolverá los espejos para el repositorio updates-testing de x86_64 para la versión 40.
El repositorio rawhide
En Rawhide – el repositorio de lanzamiento continuo de Fedora, desde el que la versión es Branched antes de finalmente convertirse en estable - rawhide es el único repositorio. Todos los paquetes compilados se envían allí. Se representa para DNF en el archivo fedora-rawhide.repo en la ruta de repositorio. Para cualquier sistema ejecutando Rawhide, debería estar habilitado. Para cualquier otro sistema no debería.
Los repositorios rawhide para las diversas arquitecturas se pueden encontrar en el directorio en los espejos y pueden también ser consultados desde MirrorManager. Por ejemplo, https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-rawhide&arch=x86_64 devolverá los espejos para el repositorio fedora x86_64 para Rawhide.
stable no es un repositorio
No es extraño ver referencias al 'repositorio estable', pero este es un nombre algo inapropiado. stable es más bien un estado que se puede considerar que existe tanto para las versiones Branched posteriores a la habilitación Bodhi y para las versiones estables. Consiste en compilaciones de paquetes que formaban parte de Rawhide en el momento en que se Ramificaron, las compilaciones de paquetes se envían directamente al repositorio fedora Ramificado entre el punto de ramificación y el punto de habilitación Bodhi y las compilaciones de paquetes que pasaron la Política de Actualizaciones y se movieron de updates-testing después del punto de habilitación Bodhi.
Para las versiones Branched, el estado stable se representa solamente por los contenidos actuales del repositorio fedora (y, definitivamente, el repositorio bleed, pero ese es un caso pequeño).
Para las versiones estables, el estado stable se representa por los contenidos del repositorio fedora combinado con los contenidos del repositorio updates.
stable también es un estado en el que se puede considerar que se encuentra un paquete(o un atributo que se puede considerar que tiene) cuando ha sido puesto estable o etiquetado estable y existe en, o existirá pronto en, un repositorio stable para una versión – cualquier repositorio literal que sea (ver arriba).
Instalación y Producto repositorios / árboles
Los repositorios mencionados anteriormente no están relacionados a un Producto Fedora.next específico ni son parte de un árbol instalable (un árbol que contiene los archivos necesarios a ser usados como repositorio base por Anaconda, el instalador Fedora). Existen repositorios especializados para estos propósitos.
Para las versiones Fedora.next – y posteriores – hay (a partir de Septiembre de 2014) un árbol no instalable no asociado con un Producto específico. Los árboles instalables para diversos Productos se pueden encontrar bajo /fedora/linux/releases/XX/ en los espejos de las versiones estables y bajo /fedora/linux/releases/test/ para los hitos antes de la liberación Branched. También pueden ser consultados desde MirrorManager. Por ejemplo, https://mirrors.fedoraproject.org/mirrorlist?repo=fedora-server-41&arch=x86_64 devolver los espejos para el repositorio de instalación actual para Server.
Estos repositorios están congelados (no se ponen en ellos nuevos paquetes) y se crean en varios puntos del Ciclo de Vida de la Versión Fedora. Un nuevo árbol de instalación (que contiene un repositorio) se construye para diversos Productos por cada prueba de composición o compilación de versión candidata y los árboles para las versiones Alpha y Beta se hacen disponibles en los espejos en el directorio (vea arriba). Contienen un subconjuntos del conjunto completo del paquete que se considera para definir cada Producto.
Los árboles de Producto para la versión GA (Final) se hacen disponibles en el árbol /releases en los espejos.
At any given point in the release cycle, the MirrorManager request for a Product repository may redirect to a test compose / release candidate tree, a pre-release milestone tree, or the Final release tree.
These repositories are usually not used or enabled by default on installed systems, as for that purpose they are redundant with one of the three primary repositories described above. However, one could use a Product repository in place of the fedora repository to keep a system limited to the Product package set. They are represented for DNF in the fedora-(product).repo file in the repository path, which may well not be installed on many systems.
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 Blocker Bug Process or 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. 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.
See a typo, something missing or out of date, or anything else which can be improved? Edit this document at https://pagure.io/fedora-docs/quick-docs.
Want to help? Learn how to contribute to Fedora Docs ›