Official repositories (Español)

Esta traducción de
Official repositories
fue revisada el
2025-12-13
. Si existen
cambios
puede
actualizarla
o avisar al
equipo de traducción
.
Artículos relacionados
Sistema de construcción de Arch
Repositorio de usuarios de Arch
makepkg
Servidores de réplica
Interfaz web de repositorios oficiales
pacman
PKGBUILD
Repositorios de usuarios no oficiales
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.
Sugerencia
Para crear un repositorio local con paquetes de
core
(u otros repositorios) sin conexión a Internet, véase
Pacman tips (Español)#Instalar paquetes desde un CD/DVD o dispositivo USB
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.
Sugerencia
Ejecute
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
)
Nota
Si el comando retorna
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 en
core
debe someterse a
core-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
.
Nota
Los repositorios de pruebas no son para las "versiones más recientes de los paquetes". Parte de su propósito es almacenar actualizaciones de paquetes que podrían afectar el sistema, ya sea por formar parte del conjunto
core
de paquetes o por ser críticos de otras maneras. Por lo tanto, se recomienda encarecidamente a los usuarios de los repositorios de pruebas que se suscriban a la
lista de correo arch-dev-public
, sigan el
foro de repositorios de pruebas
y
reportar todos los errores
. También deberían considerar unirse al
Equipo de Pruebas de Arch
.
Advertencia
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 -Syuu
para "retroceder" sus actualizaciones desde estos repositorios.
El segundo elemento es opcional, pero téngalo en cuenta si nota algún problema.
Repositorios provisionales
Advertencia
No active los repositorios
staging
por ningún motivo. Su sistema, sin duda, se romperá después de realizar una actualización. Este repositorio solo está diseñado para ser utilizado por los desarrolladores del backend.
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
.