Official repositories (Português)

Status de tradução:
Esse artigo é uma tradução de
Official repositories
. Data da última tradução: 2025-04-01. Você pode ajudar a sincronizar a tradução, se houver
alterações
na versão em inglês.
Artigos relacionados
Sistema de compilação do Arch
Arch User Repository
makepkg
Espelhos
Interface web de repositórios oficiais
pacman
PKGBUILD
Repositórios não-oficiais de usuários
Um
repositório de software
é um local de armazenamento a partir do qual pacotes de software são obtidos para instalação.
Repositórios oficiais
do Arch Linux contêm softwares essenciais e populares, prontamente acessíveis via
pacman
. Eles são mantidos por
mantenedores de pacote
.
Pacotes nos repositórios oficiais são atualizados constantemente: quando um pacote é atualizado, sua versão antiga é removida do repositórios. Não há grandes lançamentos do Arch: cada pacote é atualizado na medida em que novas versões se tornam disponíveis a partir de fontes do
upstream
. Cada repositório está sempre coerente, isto é, os pacotes que ele hospeda sempre são versões reciprocamente compatíveis.
Repositórios estáveis
core
Esse repositório pode ser localizado em
.../core/os/
de seu
espelho
favorito.
core
contém pacotes para:
inicialização do Arch Linux
conectar à Internet
compilação de pacotes
gerenciamento e correção de
sistemas de arquivos
suportados
o processo de configuração do sistema (ex.:
openssh
)
assim como as dependências deles (não necessariamente
makedepends
) e o
metapacote
base
.
core
possui uma qualidade consideravelmente estrita de requisitos. Desenvolvedores/usuários precisam assinar (como uma confirmação) as atualizações de pacotes antes delas serem aceitas; Para pacotes com baixo uso, um motivo razoável é suficiente: informar pessoas sobre a atualização, requisitar assinaturas, manter no
core-testing
por uma semana dependendo da severidade da alteração, falta de relatórios de erros relevantes, junto com o assinatura implícito do mantenedor do pacote.
Dica
Para criar um repositório local com pacotes do
core
(ou outros repositórios) sem uma conexão internet, veja
pacman/Dicas e truques#Instalando pacotes a partir de um CD/DVD ou pendrive
extra
Esse repositório pode ser localizado em
.../extra/os/
de seu espelho favorito.
extra
contém todos os pacotes que não foram para o
core
.
Este repositório é mantido de forma conjunta por
Mantenedores de Pacote
e Desenvolvedores do Arch.
Exemplos: Xorg, gerenciadores de janela, navegadores web, reprodutores de mídia, ferramentas para trabalhar com linguagens como Python e Ruby, e muito mais.
multilib
Esse repositório pode ser localizado em
.../multilib/os/
de seu espelho favorito.
multilib
contém softwares e bibliotecas 32 bits que podem ser usados para executar e compilar aplicativos 32 bits em instalações 64 bits (ex.:
wine
,
steam
, etc).
Com o repositório
multilib
habilitado, as bibliotecas compatíveis com 32 bits são colocadas sob
/usr/lib32
.
Habilitando multilib
Para usar o repositório
multilib
, descomente a seção
[multilib]
em
/etc/pacman.conf
:
/etc/pacman.conf
[multilib]
Include = /etc/pacman.d/mirrorlist
Então,
atualize
o sistema e instale os pacotes multilib desejados.
Dica
Execute
pacman -Sl multilib
para listar todos os pacotes no repositório
multilib
. Nomes de pacotes de biblioteca 32 bits começam com
lib32-
.
Desabilitando multilib
Execute o seguinte comando para remover todos os pacotes que foram instalados do
multilib
:
# pacman -R $(comm -12 <(pacman -Qq | sort) <(pacman -Slq multilib | sort))
Se você tiver conflitos com gcc-libs, reinstale o pacote
gcc-libs
e as dependências do pacote
base-devel
(Veja
Pacman/Dicas e truques#Pacotes e dependências
).
Nota
Se o comando retornar
erro: nenhum alvo definido (use -h para obter ajuda)
, significa que não há pacotes do repositório
multilib
instalados em seu sistema.
Comente a seção
[multilib]
no
/etc/pacman.conf
:
/etc/pacman.conf
#[multilib]
#Include = /etc/pacman.d/mirrorlist
Então,
atualize
o sistema.
Repositórios de teste
O objetivo pretendido dos repositórios de teste é fornecer uma área de preparação para os pacotes serem colocados antes da aceitação nos repositórios principais. Os mantenedores de pacote (e usuários em geral) podem acessar esses pacotes de teste para garantir que não haja problemas ao integrar o novo pacote. Depois que um pacote for testado e nenhum erro for encontrado, o pacote poderá ser movido para os repositórios principais.
Nem todos os pacotes precisam passar por este processo de teste. Novos os pacotes vão para um repositório de teste se:
Eles são destinados para o repositório
core
. Tudo no
core
deve passar pelo
core-testing
.
Espera-se que eles quebrem alguma coisa ao atualizar e precisem ser testados primeiro.
Eles afetam muitos pacotes (tal como
perl
ou
python
).
Os repositórios de teste também são geralmente usados para novos lançamentos de coleções grandes de pacotes, como o
GNOME
e
KDE
.
Nota
Os repositórios de teste não são servem para oferecer as versões de pacotes "mais novo do novo". Parte de seu propósito é segurar atualizações de pacotes que têm o potencial de quebrar o sistema, seja como parte do conjunto de pacotes do
core
, seja por ser crítico de outra forma. Como tal, incentivamos que os usuários de repositórios de teste se inscreverem na
lista de discussão arch-dev-public
, que acompanhem o
fórum de repositórios de testing
e que
relatem todos os erros
. Você deve considerar também se juntar à
Equipe de Teste do Arch
.
Atenção
Repositórios de teste podem conter versões de pré-lançamento de softwares.
Tenha cuidado ao habilitar os repositórios de teste. Seu sistema pode quebrar após fazer uma atualização. Apenas usuários experientes que sabem como lidar com falhas de sistema em potencial devem usá-lo.
Se você habilitar o
core-testing
, também
deve
habilitar
extra-testing
, etc. Se você habilitar qualquer outro repositório de teste listado nas subseções a seguir, você também
deve
habilitar ambos
core-testing
e
extra-testing
.
Como nem todos os pacotes nos repositórios principais têm suas versões nos repositórios de testes, os repositórios principais
core
e
extras
devem ser mantidos, e os repositórios de testes correspondentes devem estar na frente do repositório principal.
core-testing
Esse repositório pode ser localizado em
.../core-testing/os/
de seu espelho favorito.
core-testing
contém pacotes que são candidatos aos repositórios
core
.
core-testing
é o único repositório que pode ter colisões de nomes com quaisquer outros repositórios oficiais. Se habilitado, ele tem que ser o primeiro repositório listado em seu arquivo
/etc/pacman.conf
.
extra-testing
Esse repositório é similar ao repositório
core-testing
, mas para pacotes que são candidatos para o repositório
extra
.
multilib-testing
Esse repositório é similar ao repositório
core-testing
, mas para pacotes que são candidatos ao repositório
multilib
.
gnome-unstable
Esse repositório contém pacotes de teste para versões de pré-lançamento (
Alpha
,
Beta
,
RC
) e também de versões estáveis do ambiente
GNOME
, antes de sua transição para o repositório principal
extra-testing
.
Para habilitá-lo, adicione as seguintes linhas ao
/etc/pacman.conf
:
/etc/pacman.conf
[gnome-unstable]
Include = /etc/pacman.d/mirrorlist
A entrada
gnome-unstable
deve estar no topo da lista de repositórios, ou seja, em cima da entrada
core-testing
habilitado;
veja os avisos acima
.
Por favor, relate erros relacionados a empacotamento no
GitLab do Arch
, enquanto o resto deve ser relatado para o
upstream
no
Gitlab do GNOME
.
Para assistência adicional e informações sobre este repositório, junte-se à
sala Matrix
.
kde-unstable
Esse repositório contém o
beta
mais recente ou
Release Candidate
dos aplicativos e Plasma do
KDE
.
Para habilitá-lo, adicione as seguintes linhas ao
/etc/pacman.conf
:
/etc/pacman.conf
[kde-unstable]
Include = /etc/pacman.d/mirrorlist
A entrada
kde-unstable
deve estar no topo da lista de repositórios, ou seja, em cima da entrada
core-testing
habilitado);
veja os avisos acima
.
Certifique-se de
fazer relatórios de erros
se você descobrir algum problema.
Desabilitando repositórios de teste
Se você habilitou repositórios de teste, mas posteriormente decidir desabilitá-los, você deve:
Remover (comentar) eles do
/etc/pacman.conf
Realizar um
pacman -Syuu
para "retroceder" suas atualizações para esses repositórios.
O segundo item é opcional, mas tenha-o em mente caso você tenha algum problema.
Repositórios de staging
Atenção
Não ative os repositórios
staging
por qualquer motivo. Seu sistema quebrará inquestionavelmente depois de executar uma atualização. Este repositório destina-se apenas ao uso de desenvolvedores de backend.
Este repositório contém pacotes quebrados e é usado apenas por desenvolvedores durante a recompilação de muitos pacotes de uma só vez. Para recompilar os pacotes que dependem, por exemplo, de uma nova biblioteca compartilhada, a própria biblioteca compartilhada deve ser compilada e carregada nos repositórios de teste para ser disponibilizada para outros desenvolvedores. Assim que todos os pacotes dependentes forem reconstruídos, o grupo de pacotes será movido para os repositórios de teste ou para os principais, o que for mais apropriado.
Veja
o anúncio da introdução dos repositórios
staging
para mais detalhes históricos.
Revisão histórica
A maioria das divisões de repositórios ocorreram por razões históricas. Originalmente, quando o Arch Linux tinha ainda muito poucos usuários, havia apenas um repositório conhecido como
official
(agora
core
). Na época,
official
, basicamente, continha os aplicativos favoritos do Judd Vinet. Estava desenhado de maneira a conter apenas um de cada "tipo" de programa — um ambiente gráfico, um navegador, etc.
Naquela época, havia usuários que não gostavam da seleção do Judd. Então, já que o
Sistema de compilação do Arch
é tão fácil de usar, começaram a criar os seus próprios pacotes. Estes pacotes foram para um repositório chamado
unofficial
e eram mantidos por outros desenvolvedores, não o Judd. Eventualmente, os dois repositórios foram considerados pelos desenvolvedores igualmente com suporte, de forma que os nomes
official
e
unofficial
já não mais refletiam seu real propósito. Subsequentemente, estes foram renomeados para
current
e
extra
, por volta da versão 0.5.
Pouco depois do lançamento em 2007.08.1,
current
mudou para
core
para evitar confusões sobre o que ele realmente continha. Os repositórios estão agora mais ou menos iguais aos olhos da equipe e da comunidade, mas o
core
tem algumas diferenças. A distinção principal é que os pacotes usados para CDs de instalação e
snapshots
de lançamento são criados a partir do
core
, apenas. Este repositório ainda fornece um sistema Linux completo, mas pode não ser o sistema Linux que você deseja.
Por volta das versões 0.5 e 0.6, havia muitos pacotes que os desenvolvedores não queriam manter.
Jason Chu
montou os "Trusted User Repositories" (que pode ser traduzido como "repositórios dos usuários confiados"), que eram repositórios não-oficiais que os usuários considerados confiados poderiam colocar pacotes que eles tinham criado. Havia um repositório
staging
no qual pacotes poderiam ser promovidos a repositórios oficiais por um dos desenvolvedores do Arch Linux, mas fora isso, os desenvolvedores e os usuários confiados eram mais ou menos diferentes.
Isso funcionou por algum tempo, mas não quando os tais usuários confiados estavam entediados com seus repositórios e quando os outros usuários queriam compartilhar seus próprios pacotes. Isso levou ao desenvolvimento do
AUR
. Os Trusted Users foram conglomerados em um grupo bastante restrito e hoje eles mantinham o repositório
community
. Os TUs ainda eram um grupo separado dos desenvolvedores do Arch Linux e não havia muita comunicação entre eles. Porém, pacotes populares ainda eram por vezes promovidos do
community
para
extra
. O
AUR
também permite que todos os usuários enviem seus PKGBUILDs.
Após um kernel no
core
quebrar o sistema de muitos usuários
, a
"core signoff policy"
("política de assinatura do core") foi introduzida. Desde então, todas as atualizações de pacotes para o
core
precisam passar pelo repositório
core-testing
primeiro e apenas após múltiplas assinaturas de outros desenvolvedores ou pessoas na
Equipe de Teste do Arch
que, então, são permitidos mover. Ao longo do tempo, foi notado que vários pacotes do
core
tinham pouco uso, e signoffs de usuários ou até mesmo falta de relatórios de erros se tornaram informalmente aceitos como critério para aceitar tais pacotes.
No final de 2009 e o início de 2010, com o advento de novos sistemas de arquivos, o desejo de oferecer suporte durante a instalação e com a percepção de que o
core
nunca foi claramente definido (apenas "pacotes importantes, escolhido a mão pelos desenvolvedores"), o repositório recebeu uma descrição mais precisa.
Desde 2021, e concluído no final de 2023, os "Trusted User" foram renomeados para "Package Maintainers" (Mantenedores de Pacote, na versão traduzida deste ArchWiki).
Em 2023, após anos de trabalho, a distribuição
migrou seus serviços de back-end para git
e na mesma ocasião também mudou para um novo layout de repositórios. No novo layout,
extra
conteria todos os pacotes que estavam anteriormente em
community
e os repositórios de teste foram divididos de
testing
para
core-testing
e
extra-testing
,
community-testing
foi totalmente removido. A partir desse ponto, os
Mantenedores de Pacote
também passaram poder enviar novos pacotes para
extra
.