Official repositories (Español)
Un repositorio de software es un lugar donde se almacenan los paquetes de software, los cuales pueden ser recuperados e instalados en un ordenador.
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 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. Ejemplo: Xorg, gestores de ventanas, navegadores web, reproductores multimedia, herramientas para trabajar con lenguajes como Python y Ruby, y mucho más.
community
Este repositorio se encuentra en .../community/os/ en su servidor de réplica favorito.
community contiene paquetes que han sido adoptados por Usuarios de confianza, generalmente del Repositorio de usuarios de Arch. Algunos de estos paquetes eventualmente pueden hacer la transición a los repositorios core o extra cuando los desarrolladores los consideran cruciales para la distribución.
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 wine, 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 el grupo base-devel.
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. Sin embargo, todos los paquetes destinados al repositorio core deben ir primero a testing. Los paquetes que pueden afectar a muchos paquetes (como perl o python) también deben probarse. testing también se utiliza generalmente para grandes colecciones de paquetes como GNOME y KDE.
- Tenga cuidado al activar los repositorios testing. Su sistema puede fallar después de realizar una actualización. Solo los usuarios experimentados que saben cómo lidiar con posibles fallos en el sistema deben utilizarlo.
- Si activa testing, también debe activar community-testing. Si activa cualquier otro repositorio de pruebas listado en las siguientes subsecciones, también debe activar tanto testing como community-testing.
testing
Este repositorio se encuentra en .../testing/os/ en su servidor de réplica favorito.
testing contiene paquetes que son candidatos para los repositorios core o extra.
Los nuevos paquetes entran en testing si:
- Están destinados al repositorio core. Todo en core debe pasar por testing.
- Se espera que rompan algo en la actualización y deben probarse primero.
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.
community-testing
Este repositorio es similar al repositorio testing pero con los paquetes que son candidatos para el repositorio community.
multilib-testing
Este repositorio es similar al repositorio testing pero con los paquetes que son candidatos para el repositorio multilib.
gnome-unstable
Este repositorio contiene paquetes de prueba para la próxima versión candidata o estable del entorno de escritorio GNOME, antes de que se trasladen al repositorio 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 testing).
Informe los errores relacionados con el empaquetado en nuestro rastreador de fallos, mientras que cualquier otra cosa debe informarse al upstream en el Gitlab de GNOME.
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 testing).
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 funciono por un tiempo, pero luego los Usuarios de Confianza comenzaron a descuidar su repositorio, mientras que los usuarios normales 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 son un grupo separado de los desarrolladores de Arch Linux y no existe mucha comunicación entre ambos colectivos. Sin embargo, los paquetes populares aun siguen siendo derivados desde community a extra, en ocasiones. El repositorio AUR también permite a usuarios que no tienen la clasificación de "Trusted Users" (usuarios de confianza) 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 un repositorio testing , y únicamente después de la aprobación de varios desarrolladores 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.