Repositorios Fedora

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.

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-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.

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.

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).

El repositorio bleed existe para un sencillo propósito: durante los Hitos congelados, contiene paquetes que han obtenido 'excepciones de congelación' por medio del Proceso de Bloquear Error o el proceso de Excepción de Congelación de error y que se desea que sean incluidos en la siguiente compilación para prueba de composición o versión candidata, pero que todavía no ha alcanzado el estado estable y por lo tanto llevados al repositorio fedora. En otras palabras, contiene paquetes explícitamente requeridos en las solicitudes de composición TC/RC.

El repositorio bleed se encuentra aquí, pero de nuevo, no es normalmente de interés para la gran mayoría de los usuarios de Fedora. Los paquetes que contiene están siempre disponibles desde el sistema de compilación, Koji, y normalmente desde el repositorio updates-testing.

Los repositorios latest contienen paquetes de diversas 'etiquetas' de compilación según llegan al sistema de compilación Koji. No están triturados, un proceso que maneja principalmente multilib y su uso puede causar varios problemas, además de sobrecargar los servidores de desarrollo de Fedora. Casi siempre es mejor idea seleccionar nuevas compilaciones de Koji o Bodhi por medio de sus interfaces web o herramientas de línea de comandos.

Como se ha descrito anteriormente, las actualizaciones para las versiones preliminares Branched como para las finales y stable pasan por un proceso de updates-testing antes de ser llevadas al repositorio stable. Antes de la versión final, se ponen en el repositorio fedora. Después del lanzamiento, se ponen en updates.

La razón de la diferencia es que deseamos tener un registro de 'estado' exacto de una versión Fedora estable dada. Esto es, en el momento que una versión de Fedora se declara hecha en una Reunión Va/No Va, consideramos el estado de versión en ese momento como la definición canónica de esa versión y deseamos guardar un registro de ese estado. Para una versión estable, el árbol que contiene el repositorio fedora es ese registro y lo que el repositorio fedora contiene es el registro canónico del conjunto preciso de paquetes frozen que forman la parte principal de esa versión estable.

Dado que deseamos mantener ese estado frozen para el repositorio fedora, no podemos colocar actualizaciones directamente en él. La necesidad del repositorio updates, por lo tanto, es obvia – necesitamos poner las actualizaciones de las versiones estables en un lugar fuera del estado frozen de la versión.

Antes de llegar a la versión estable, este mecanismo no es necesario. Antes de que se declara la versión como hecha, no hay estado frozen de la versión: efectivamente, el proceso entero de desarrollo Branched es un trabajo hacia lo que llegará a ser el estado frozen de la versión, así que, desde luego, los paquetes construidos para la versión Branched aterrizan directamente en el repositorio fedora.

Aunque las versiones de desarrollo Branched y la versión estable usan un repositorio updates-testing junto con el sistema de comentarios de actualización Bodhi para poner en escena los paquetes antes de que alcancen el estado stable de la versión, está habilitado de modo predeterminado en Branched, pero no en las versiones estables.

La razón es que el propósito del sistema updates-testing es algo diferente en cada caso. Para las versiones estables, el objetivo del sistema es evitar que las actualizaciones rotas alcancen una población general entre los usuarios de Fedora. En la mayoría de los casos, los sistemas Fedora esperan tener el repositorio updates-testing deshabilitado. Algunos evaluadores de QA (Garantía de Calidad) habilitan el repositorio sobre los sistemas de pruebas para probar las actualizaciones y proporcionar comentarios. Los evaluadores llevan a cabo el trabajo de asegurar que las actualizaciones están bien antes de que alcancen la población general de usuarios.

Cuando se trata de una versión preliminar Branched, la expectativa es que cualquiera que la instale pueda llegar a probarla: nosotros, efectivamente, consideramos que cualquiera que ejecute una versión Branched es un evaluador. La función de updates-testing en este caso es diferente. No existe una 'población general de usuarios' de Branched que lo ejecuten con updates-testing deshabilitado y estén protegidos de actualizaciones problemáticas por el grupo de evaluadores de actualización. En su lugar, updates-testing en Branched cumple otras funciones importantes.

El objetivo principal es aislar la_ creación de imágenes_ de cambios potencialmente problemáticos. Las imágenes – imágenes nocturnas y las compilaciones de hitos Alpha, Beta y GA (Final) y sus composiciones candidatas de prueba y lanzamiento – se construyen desde paquetes estables, esto es, solo aquellos del repositorio fedora, no los que están en updates-testing. En este sentido, updates-testing protege no a un conjunto de usuarios, sino a un conjunto de compilaciones de cambios potencialmente desestabilizadores. Especialmente cuando estamos compilando una versión Alpha, Beta o GA, necesitamos reducir la cantidad de cambios en el conjunto de paquetes entre composiciones con el objetivo de producir una imagen de alta calidad. El mecanismo de updates-testing permite por esto: durante los Hitos congelados, se pueden enviar nuevas compilaciones a updates-testing, pero no se pueden mover de allí a stable (fedora) sin circunstancias especiales. De este modo, podemos trabajar en las imágenes de la versión sin evitar que los empaquetadores puedan mandar compilaciones.

Para esta y otras funciones menos importantes, necesitamos tantos comentarios como sea posible, por lo que tiene sentido que todos los evaluadores previos al lanzamiento tengan habilitado updates-testing de modo predeterminado y les alentamos a proporcionar comentarios a través de Bodhi.

¿Vea algún error tipográfico, algo desaparecido o desactualizado o algo que pueda ser mejorado? Edite este documento en https://pagure.io/fedora-docs/quick-docs.