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 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.: )
assim como as dependências deles (não necessariamente makedepends) e o metapacote .
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 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. Por exemplo: Xorg, gerenciadores de janela, navegadores web, reprodutores de mídia, ferramentas para trabalhar com linguagens como Python e Ruby, e muito mais.
community
Esse repositório pode ser localizado em de seu espelho favorito.
community contém pacotes que foram adotadores por Trusted Users do Arch User Repository. Alguns desses pacotes podem eventualmente serem movidos para os repositórios core ou extra caso os desenvolvedores os considerem cruciais para a distribuição.
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.: , , etc).
Com o repositório multilib habilitado, as bibliotecas compatíveis com 32 bits são colocadas sob .
Habilitando multilib
Para usar o repositório multilib, descomente a seção em :
Então, atualize o sistema e instale os pacotes multilib desejados.
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 e o grupo base-devel.
Comente a seção no :
Então, atualize o sistema.
Repositórios de teste
O objetivo pretendido do repositório testing é fornecer uma área de preparação para os pacotes serem colocados antes da aceitação nos repositórios principais. Os mantenedores de pacotes (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. No entanto, todos os pacotes destinados ao repositório core devem ir para testing primeiro. Pacotes que podem afetar muitos pacotes (como ou ) também devem ser testados. O teste também é geralmente usado para grandes coleções de pacotes como GNOME e KDE.
testing
Esse repositório pode ser localizado em .../multilib/os/ de seu espelho favorito.
testing contém pacotes que são candidatos aos repositórios core ou extra.
Novos pacotes vão para o testing se:
- Eles são destinados ao repositório core. Tudo no core deve passar pelo testing
- Espera-se que eles quebrem alguma coisa ao atualizar e precisarem ser testados primeiro.
testing é o único repositório que pode ter colisões nos nomes com outros repositórios oficiais. Se ativo, ele tem de ser o primeiro repositório listado em seu arquivo .
community-testing
Esse repositório é similar ao repositório testing, mas para pacotes que são candidatos para o repositório community.
multilib-testing
Esse repositório é similar ao repositório 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 testing.
Para habilitá-lo, adicione as seguintes linhas ao :
[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 testing).
Por favor, relate erros relacionados a empacotamento em nosso rastreador de erro, 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 :
[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 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
- Realizar um 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
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 o teste ou para os repositórios 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 Arch Build System é 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 usuários não-confiados 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 mantêm o repositório community. Os TUs ainda são um grupo separado dos desenvolvedores do Arch Linux e há muita comunicação entre eles. Porém, pacotes populares ainda são por vezes promovidos do community para extra. O AUR também permite que os demais usuários (não-TUs)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 testing primeiro e apenas após múltiplas assinaturas de outros desenvolvedores 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.