Official repositories (Español)
Un repositorio de software es una ubicación de almacenamiento desde donde se recuperan los paquetes de software para su instalación.
Los repositorios oficiales de Arch Linux contienen software esencial y popular, fácilmente accesible a través de pacman. Son mantenidos por los mantenedores de paquetes.
Los paquetes en los repositorios oficiales se actualizan constantemente: cuando se actualiza un paquete, su versión anterior se elimina del repositorio. No hay lanzamientos importantes de Arch: cada paquete se actualiza a medida que hay nuevas versiones disponibles de fuentes ascendentes. Cada repositorio es siempre coherente, es decir, los paquetes que aloja siempre tienen versiones recíprocamente compatibles.
Repositorios estables
core
Este repositorio se encuentra en .../core/os/ desde su servidor de réplica favorito.
core contiene paquetes para:
- Arrancar Arch Linux
- Conectar a Internet
- construir paquetes
- Gestionar y reparar sistemas de archivos compatibles
- Configurar el sistema (por ejemplo openssh)
así como las dependencias de lo anterior (no necesariamente makedepends) y el metapaquete base.
core tiene requisitos de calidad bastante estrictos. Los desarrolladores/usuarios deben aprobar las actualizaciones antes de que se acepten las actualizaciones de paquetes. Para paquetes con poco uso, una exposición razonable es suficiente: informar a las personas sobre la actualización, solicitar aprobaciones, mantener core-testing hasta una semana dependiendo de la gravedad del cambio, falta de informes de errores pendientes, junto con la aprobación implícita del mantenedor del paquete.
extra
Este repositorio se encuentra en .../extra/os/ en su servidor de réplica favorito.
extra contiene todos los paquetes que no encajan en core. Este repositorio es conjuntamente mantenido por los Mantenedores de Paquetes y los Desarrolladores de Arch. Ejemplos: Xorg, gestores de ventanas, navegadores web, reproductores multimedia, herramientas para trabajar con lenguajes como Python y Ruby, y mucho más.
multilib
Este repositorio se encuentra en .../multilib/os/ en su servidor de réplica favorito.
multilib contiene software y bibliotecas de 32 bits que se pueden utilizar para ejecutar y crear aplicaciones de 32 bits en instalaciones de 64 bits (por ejemplo steam, etc).
Con el repositorio multilib activado, las bibliotecas compatibles de 32 bits se encuentran en /usr/lib32/.
Activar multilib
Para activar el repositorio multilib, descomente la sección [multilib] en /etc/pacman.conf:
/etc/pacman.conf
[multilib] Include = /etc/pacman.d/mirrorlist
Luego actualice el sistema e instale los paquetes multilib deseados.
pacman -Sl multilib para listar todos los paquetes del repositorio multilib. Los nombres de los paquetes de biblioteca de 32 bits comienzan con lib32-.Desactivar multilib
Ejecute la siguiente orden para eliminar todos los paquetes que se instalaron desde multilib:
# pacman -R $(comm -12 <(pacman -Qq | sort) <(pacman -Slq multilib | sort))
Si tiene conflictos con gcc-libs, reinstale el paquete gcc-libs y las dependencias del paquete base-devel (Véase Pacman (Español)/Tips and tricks (Español)#Paquetes y dependencias)
error: no se especificaron objetivos (use -h para ayuda) esto significa que no hay paquetes del repositorio multilib instalados en tu sistema.Comente la sección [multilib] en /etc/pacman.conf:
/etc/pacman.conf
#[multilib] #Include = /etc/pacman.d/mirrorlist
Luego actualice el sistema.
Repositorios de prueba
El propósito previsto del repositorio testing es proporcionar un área de preparación para que los paquetes se coloquen antes de su aceptación en los repositorios principales. Los mantenedores de paquetes (y los usuarios en generales) pueden acceder a estos paquetes de prueba para asegurarse de que no haya problemas para integrarlos. Una vez que se ha probado un paquete y no se encuentran errores, el paquete se puede mover a los repositorios principales.
No todos los paquetes necesitan pasar por este proceso de prueba. Los nuevos paquetes van a un repositorio de pruebas si:
- Están destinados al repositorio
core. Todo encoredebe someterse acore-testing. - Se espera que presenten algún fallo al actualizarse y deben probarse primero.
- Afectan a muchos paquetes (como perl o python).
- Los crea un Mantenedor de Paquetes Junior.
Los repositorios testing son también usualmente usados para nuevos lanzamientos de grandes colecciones de paquetes como GNOME y KDE.
- Los repositorios de prueba pueden contener versiones preliminares del software.
- Tenga cuidado al habilitar los repositorios de prueba. Su sistema podría fallar después de realizar una actualización. Solo usuarios experimentados que sepan cómo gestionar posibles fallas del sistema deberían usarlos.
- Si habilita core-testing, también debe habilitar extra-testing, y viceversa. Si habilita cualquier otro repositorio de prueba mencionado en las siguientes subsecciones, también debe habilitar core-testing y extra-testing.
- Dado que no todos los paquetes de los repositorios principales tienen sus versiones en los repositorios de prueba, se deben conservar los repositorios principales core y extra, y los repositorios de prueba correspondientes deben estar delante del repositorio principal.
core-testing
Este repositorio se encuentra en .../core-testing/os/ en su servidor de réplica favorito.
core-testing contiene paquetes que son candidatos para el repositorio core.
core-testing es el único repositorio que puede tener colisiones de nombres con cualquiera de los otros repositorios oficiales. Si está activado, tiene que ser el primer repositorio listado en su archivo /etc/pacman.conf.
extra-testing
Este repositorio es similar al repositorio core-testing pero con los paquetes que son candidatos para el repositorio extra.
multilib-testing
Este repositorio es similar al repositorio core-testing pero con los paquetes que son candidatos para el repositorio multilib.
gnome-unstable
Este repositorio contiene paquetes de prueba para los pre lanzamientos (Alpha, Beta, RC) así como versiones estables del entorno de escritorio GNOME, antes de que se trasladen al repositorio extra-testing principal.
Para activarlo, añada las siguientes líneas a /etc/pacman.conf:
[gnome-unstable] Include = /etc/pacman.d/mirrorlist
La entrada gnome-unstable debe estar primero en la lista de repositorios (es decir, antes de la entrada core-testing; Vea las advertencias de arriba).
Informe los errores relacionados con el empaquetado en nuestro GitLab de Arch, mientras que cualquier otra cosa debe informarse al upstream en el Gitlab de GNOME.
Para obtener ayuda adicional e información sobre este repositorio, por favor únase al Grupo de Matrix.
kde-unstable
Este repositorio contiene la última beta o Release Candidate (candidato de liberación) de Plasma de KDE y Aplicaciones.
Para activarlo, añada las siguientes líneas a /etc/pacman.conf:
[kde-unstable] Include = /etc/pacman.d/mirrorlist
La entrada kde-unstable debe estar primero en la lista de repositorios (es decir, antes de la entrada core-testing Vea las advertencias de arriba).
Asegúrese de hacer informes de errores si encuentra algún problema.
Desactivar repositorios de prueba
Si activó los repositorios de prueba, pero luego decidió desactivarlos, debe:
- Eliminarlos (comentarlos) de
/etc/pacman.conf - Realizar un
pacman -Syuupara "retroceder" sus actualizaciones desde estos repositorios.
El segundo elemento es opcional, pero téngalo en cuenta si nota algún problema.
Repositorios provisionales
Este repositorio contiene paquetes rotos y lo usan únicamente los desarrolladores durante las reconstrucciones de muchos paquetes a la vez. Para reconstruir paquetes que dependen, por ejemplo de una nueva biblioteca compartida, la propia biblioteca compartida primero debe construirse y cargarse en los repositorios de prueba para que esté disponible para otros desarrolladores. Tan pronto como se reconstruyen todos los paquetes dependientes, el grupo de paquetes se mueve a testing o a los repositorios principales, lo que sea más apropiado.
Véase el anuncio de la introducción de los repositorios staging para más detalles históricos.
Antecedentes históricos
La mayoría de los grupos de repositorios existen por razones históricas. Originalmente, cuando Arch Linux era usada por muy pocos usuarios, solo había un depósito conocido como official (ahora core). En el momento, official contenía básicamente las aplicaciones preferidas de Judd Vinet. Cada grupo estaba diseñado para contener un programa para cada "tipo" de aplicación: un entorno de escritorio, un navegador, etc.
En aquel entonces existían algunos usuarios a los que no les gustaba las selecciones de Judd, y dado que el ABS era fácil de usar, comenzaron a crear sus propios paquetes. Estos paquetes fueron incorporados a un repositorio llamado unofficial y fueron mantenidos por algunos desarrolladores de Judd. Con el tiempo estos dos repositorios consiguieron apoyo por parte de todos los desarrolladores. Como los nombres oficial y unoficial ya no reflejaban su verdadero propósito fueron renombrados a current y extra en torno a la versión 0.5.
Poco tiempo después del lanzamiento de la versión 2007.08.01, current fue renombrado a core para prevenir confusiones sobre lo que contenía. Los repositorios ahora se encuentran atendidos por igual por los desarrolladores y la comunidad, pero core tiene algunas diferencias, la principal es que los paquetes para el CD de instalación y las liberaciones de instantáneas (snapshots) son tomados solo de core. Este repositorio aun provee un completo sistema Linux, pero puede no ser el sistema que desee.
En algún momento entre versión 0.5 y la 0.6, se descubrió que existían muchos paquetes que los desarrolladores no querían mantener. Jason Chu preparó el "Repositorio de usuarios de confianza" (Trusted User Repositories) que era básicamente un repositorio no oficial en el cual los usuarios de confianza podían colocar paquetes que ellos hubieran creado. Existió un repositorio staging, donde los paquetes podían ser derivados a uno de los repositorios oficiales mantenidos por los desarrolladores de Arch Linux, pero a parte de esto, los desarrolladores y usuarios de confianza se han mantenidos más o menos distintos.
Este sistema funcionó por un tiempo, pero luego los Usuarios de Confianza comenzaron a descuidar su repositorio, mientras que los otros usuarios deseaban compartir sus paquetes. Esto llevo al desarrollo del repositorio AUR. Los Usuarios de Confianza fueron congregados en un grupo más unido y ahora mantienen colectivamente el repositorio community. Los usuarios de confianza aun fueron un grupo separado de los desarrolladores de Arch Linux y no existió mucha comunicación entre ambos colectivos. Sin embargo, los paquetes populares aun siguían siendo derivados desde community a extra, en ocasiones. El repositorio AUR también permite a todos los usuarios enviar PKGBUILDs.
Después de numerosos problemas causados por un kernel introducido en core , fue presentada la norma "core signoff policy" (política deaprobación de core). Desde entonces, todas las actualizaciones de los paquetes depositados en core tienen que ser presentados primero a través de el repositorio core-testing , y únicamente después de la aprobación de varios desarrolladores o personas en el Equipo de Pruebas de Arch se les permite moverse a core. Con el tiempo, se observó que algunos paquetes destinados a core tenían poco uso, para este tipo de paquetes la aprobación de los usuarios o, incluso, la falta de informes de errores, se aceptó oficiosamente como criterio para admitirlos.
A finales de 2009/principios de 2010, con la llegada de unos nuevos sistemas de archivos y el deseo de apoyarlos durante la instalación, junto con la conciencia de que core nunca se definió claramente (simplemente "paquetes importantes, seleccionados por los desarrolladores"), los repositorios recibieron una descripción más precisa.
A partir de 2021 y hasta finales de 2023, los "Trusted Users" (Usuarios de confianza) pasaron a llamarse "Package Maintainers" (Mantenedores de Paquetes).
En 2023, tras años de trabajo previo, la distribución migró sus servicios de back-end a git y en la misma ejecución también cambió a un nuevo diseño de repositorio. En el nuevo diseño extra contendría todos los paquetes que previamente estaban en community y los repositorios de prueba fueron divididos de testing a core-testing y extra-testing, comunnity-testing fue removido completamente. A partir de ese momento, los Matenedores de Paquetes también pudieron enviar nuevos paquetes a extra.