Official repositories (Português)
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.
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.
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).
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.
- 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 o próximo lançamento estável ou candidato a lançamento estável do ambiente GNOME, antes de serem movidos para o repositório principal de teste 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 primeiro na lista de repositórios, ou seja, em cima da entrada core-testing).
Por favor, relate erros relacionados a empacotamento no GitLab do Arch, enquanto o resto deve ser relatado para o upstream no Gitlab do GNOME.
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 primeiro na lista de repositórios, ou seja, em cima da entrada core-testing).
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 -Syuupara "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
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 TUs foram conglomerados em um grupo bastante restrito denominado Trusted Users e hoje eles mantinham o repositório community. Os Trusted Users 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.