Difference between revisions of "Official repositories (Português)"

From ArchWiki
Jump to: navigation, search
(rm temporary i18n template)
(testing: if anything deserves to be red, it's this paragraph)
 
(32 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 
[[Category:Package management (Português)]]
 
[[Category:Package management (Português)]]
 
[[Category:About Arch (Português)]]
 
[[Category:About Arch (Português)]]
[[cs:Official Repositories]]
+
[[ar:Official repositories]]
[[en:Official Repositories]]
+
[[cs:Official repositories]]
[[es:Official Repositories]]
+
[[en:Official repositories]]
 +
[[es:Official repositories]]
 
[[fr:Depots]]
 
[[fr:Depots]]
[[it:Official Repositories]]
+
[[it:Official repositories]]
[[nl:Official Repositories]]
+
[[ja:公式リポジトリ]]
[[ru:Official Repositories]]
+
[[nl:Official repositories]]
[[tr:Resmi_Depolar]]
+
[[ro:Depozitele oficiale]]
[[zh-CN:Official Repositories]]
+
[[ru:Official repositories]]
[[zh-TW:Official Repositories]]
+
[[tr:Resmi Depolar]]
:''Uma vez que existe uma enorme confusão acerca dos repositórios de Arch, esta wiki tenta explicar o seu significado:''
+
[[zh-hans:Official repositories]]
 +
[[zh-hant:Official repositories]]
 +
{{Related articles start (Português)}}
 +
{{Related|Arch Build System (Português)}}
 +
{{Related|Arch User Repository (Português)}}
 +
{{Related|makepkg (Português)}}
 +
{{Related|Mirrors}}
 +
{{Related|pacman (Português)}}
 +
{{Related|PKGBUILD (Português)}}
 +
{{Related|Unofficial user repositories}}
 +
{{Related articles end}}
 +
Um [[Wikipedia:software repository|repositório de software]] é um local de armazenamento a partir do qual pacotes de software são obtidos para instalação.
  
= Revisão histórica =
+
'''Repositórios oficiais''' do Arch Linux contêm softwares essenciais e populares, prontamente acessíveis via [[pacman (Português)|pacman]]. Eles são mantidos por [[Arch terminology (Português)#Package maintainer|mantenedores de pacote]].
  
A maioria das divisões ocorreram por razões históricas. Originalmente, quando esta distribuição tinha ainda muito poucos utilizadores, havia um só repositório, que hoje corresponde ao [core] -- chamado [official]. Este repositório era composto, basicamente, pelas aplicações favoritas do Judd, apesar de não ser esse o caso hoje em dia. Está desenhado de maneira a ter apenas um de cada "tipo" de programa -- um desktop environment, um browser, etc.
+
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.
  
Nessa altura havia utilizadores que não gostavam das preferências de Judd, como o [[Arch Build System]] é tão simples de usar, começaram a criar os seus próprios pacotes. Estes pacotes foram para um repositório chamado [unofficial] e eram mantidos por programadores que não Judd. Os dois repositórios tornaram-se igualmente suportados pelos programadores e os nomes[oficial] e [unofficial] já não faziam sentido. Estes mudaram de nome para [current] e [extra], por volta do lançamento versão 0.5.
+
== Repositórios ==
Pouco depois do lançamento da 2007.08.1, [current] mudou para [core] para evitar confusões relativamente ao que realmente contém. Os repositórios são hoje bastante iguais aos olhos quer da equipa quer da comunidade, mas o [core] tem algumas diferenças, sendo que a principal é a de que os CDs de instalação têm os pacotes apenas do [core]. Este repositório dá um sistema GNU/Linux completo, mas pode não ser o que se quer.
 
  
Algures entre as versões 0.5 e 0.6, verificou-se que havia muitos pacotes que a equipa não queria manter. Um dos programadores (Xentac) configurou os "Repositórios de Utilizadores de Confiança (Trusted User Repositories)", que eram repositórios não-oficiais onde utilizadores de confiança (UC) podiam pôr os pacotes que criavam. Havia um repositório [staging] onde os pacotes podiam ser promovidos pela equipa para entrar nos repositórios oficiais, mas à parte disto a equipa e esses utilizadores eram mais ou menos de confiança.
+
=== core ===
  
Isto funcionou por algum tempo, excepto quando os utilizadores de confiança se cansaram dos seus repositórios e os restantes utilizadores queriam também partilhar os seus pacotes. Isto levou ao desenvolvimento do [https://aur.archlinux.org/ AUR]. Os utilizadores de confiança foram conglomerados num grupo bastante restrito e hoje mantêm em conjunto o repositório [community]. Os UC ainda são um grupo separado da equipa principal e não há muita comunicação entre eles. No entanto, pacotes populares são por vezes promovidos do [community] para o [extra]. O [https://aur.archlinux.org/ AUR] também que permite os restantes utilizadores submetam os seus [[PKGBUILD]]s para que outros os usem, se assim desejarem. Estes pacotes não são suportados, daí o repositório se chamar [unsupported], apesar de nenhuns binários serem distribuidos, pelo que o [unsupported] não é bem um repositório. Os UC podem adoptar pacotes do [unsupported] para o [community] à sua discrição, quer seja por o pacote ser popular ou por terem interesse em mantê-lo.
+
Esse repositório pode ser localizado em {{ic|.../core/os/}} de seu [[mirror]] favorito.
  
= Lista de repositórios =
+
''core'' contém pacotes para:
  
== [core] ==
+
* inicialização do Arch Linux
 +
* [[Network configuration (Português)|conectar à Internet]]
 +
* [[Creating packages (Português)|compilação de pacotes]]
 +
* gerenciamento e correção de [[file systems|sistemas de arquivos]] suportados
 +
* o processo de configuração do sistema (ex.: {{Pkg|openssh}})
 +
assim como as dependências deles (não necessariamente [[PKGBUILD (Português)#makedepends|makedepends]]).
  
O repositório [core] pode ser encontrado no ''core/os/i686'' ou ''core/os/x86_64'' no teu mirror favorito. Contém os pacotes principais de Arch e algum software adicional e irá fornecer um sistema básico totalmente funcional.
+
''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.
  
''O CD de Instalação não é mais do que um script de instalação e uma cópia do repositório [core]''
+
{{Nota|Para criar um repositório local com pacotes do ''core'' (ou outros repositórios) sem uma conexão internet, veja [[Pacman tips#Installing packages from a CD/DVD or USB stick]]}}
  
== [extra] ==
+
=== extra ===
  
O repositório [extra] pode ser encontrado em ''extra/os/i686'' ou ''extra/os/x86_64'' no teu mirror favorito. Contém todos os pacotes oficiais de Arch que não foram para o [core]. Por exemplo: X.org, gerenciadores de janela, servidores web, reprodutores de media, línguas como Python, Ruby e Perl, e bastante mais.
+
Esse repositório pode ser localizado em {{ic|.../extra/os/}} de seu ''mirror'' favorito.
  
== [community] ==
+
''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.
  
O repositório [community] pode ser encontrado em ''community/os/i686'' ou ''community/os/x86_64'' no teu mirror favorito. Este é mantido pelos  ''Utilizadores de Confiança (UC)'' e faz parte do ''Arch User Repository (AUR)''. Contém os pacotes do ''AUR'' com votos suficientes ou que tenham sido adoptados por um ''UC''.
+
=== community ===
  
== [testing] ==
+
Esse repositório pode ser localizado em {{ic|.../comunidade/os/}} de seu ''mirror'' favorito.
  
O repositório [testing] pode ser encontrado em ''testing/os/i686'' ou ''testing/os/x86_64'' no teu mirror favorito. [testing] é especial. Este contém pacotes que são candidatos ao [core], [extra] ou ao [unstable]. Pacotes novos vão para o [testing] se:
+
''community'' contém pacotes que foram adotadores por [[Trusted Users (Português)|Trusted Users]] do [[Arch User Repository (Português)|Arch User Repository]]. Alguns desses pacotes podem eventualmente serem movidos para os repositórios [[#core|core]] ou [[#extra|extra]] caso os desenvolvedores os considerem cruciais para a distribuição.
* podem danificar alguma coisa após o update e precisam de ser testados primeiro.
 
* exigem outros pacotes para ser reconstruidos. Neste caso, todos os pacotes que precisam de ser reconstruidos são colocados no [testing] primeiro e quando todos estiverem concluidos, são movidos para o repositório respectivo.
 
  
[testing] é o único repositório que pode ter colisões nos nomes com outros repositórios oficiais. Se activo, tem de ser o primeiro listado no ficheiro {{ic|/etc/pacman.conf}}.
+
=== multilib ===
  
Cuidado ao activar o repositório [testing]. O teu sistema pode ficar danificado após updates com pacotes provenientes do [testing]. O seu uso deve estar limitado a uilizadores que sabem o que estão a fazer.
+
Esse repositório pode ser localizado em {{ic|.../multilib/os/}} de seu ''mirror'' favorito.
  
== [unsupported] ==
+
''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.: {{Pkg|wine}}, {{Pkg|steam}}, etc).
  
O repositório [unsupported] não é bem um repositório. Ao contrário dos outros repositórios, este não contém pacotes binários. É usado para referir a colecção [[PKGBUILD]]s no AUR que foram submetidos por utilizadores comuns, pelo que o [unsupported] não é verdeiramente oficial.
+
Para mais informações, veja [[Multilib]].
Não se pode descarregar ou instalar pacotes do [unsupported] com o [[pacman]]. Tem de se descarreguegá-los manualmente e compilar os binários, ou usar um do popular [[AUR Helpers]] para fazer isso automaticamente.
+
 
 +
=== testing ===
 +
 
 +
{{Atenção|Cuidado ao ativar o repositório ''testing''. Seu sistema pode não funcionar adequadamente ao realizar uma atualização. Apenas usuários experientes que sabem como lidar com falhas de sistema em potencial devem usá-lo.}}
 +
 
 +
Esse repositório pode ser localizado em {{ic|.../multilib/os/}} de seu ''mirror'' 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 {{ic|/etc/pacman.conf}}.
 +
 
 +
{{Nota|''testing'' não é para 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 da coleção de pacotes do ''core'', seja como crítico de outras formas. Como tal, usuários do ''testing'' são incentivados a se inscreverem na [https://mailman.archlinux.org/mailman/listinfo/arch-dev-public lista de discussão arch-dev-public], acompanhar o [https://bbs.archlinux.org/viewforum.php?id=49 fórum do repositório testing] e a [[Reporting bug guidelines|relatar todos os erros]].}}
 +
 
 +
{{warning|Se você habilitar ''testing'', também deve habilitar ''community-testing''. Se você habilitar qualquer outro repositório de teste listado nas subseções a seguir, você também deve habilitar ambos ''testing'' e ''community-testing''.}}
 +
 
 +
==== 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 a versão mais recente do ambiente gráfico do [[GNOME]], antes de ser movido para o repositório principal de teste ''testing''.
 +
 
 +
Para habilitá-lo, adicione as seguintes linhas ao {{ic|/etc/pacman.conf}}:
 +
 
 +
[gnome-unstable]
 +
Include = /etc/pacman.d/mirrorlist
 +
 
 +
A entrada ''gnome-unstable'' deve estar primeiro na lista de repositórios (''i.e.'', acima da entrada ''testing'').
 +
 
 +
Por favor, relate erros relacionados a empacotamento em nosso [https://bugs.archlinux.org/ rastreador de erro], enquanto o resto deve ser relatado para o ''upstream'' no [https://bugzilla.gnome.org/ Bugzilla 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 {{ic|/etc/pacman.conf}}:
 +
 
 +
[kde-unstable]
 +
Include = /etc/pacman.d/mirrorlist
 +
 
 +
A entrada ''kde-unstable'' deve estar primeiro na lista de repositórios (''i.e.'', em cima da entrada ''testing'').
 +
 
 +
Certifique-se de [[Reporting bug guidelines|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 {{ic|/etc/pacman.conf}}
 +
# Realizar um {{ic|# pacman -Syuu}} para "retroceder" suas atualizações para esses repositórios.
 +
 
 +
O segundo item é opcional, mas tenha-o em mente que cas você tenha algum problema.
 +
 
 +
== 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 (Português)|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. [https://www.archlinux.org/fellows/#jason 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 [https://aur.archlinux.org/ 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 [https://aur.archlinux.org/ AUR] também permite que os demais usuários (não-TUs)enviem seus PKGBUILDs.
 +
 
 +
Após um kernel no ''core'' [https://www.archlinux.org/news/please-avoid-kernel-261614-1/ 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.

Latest revision as of 01:58, 12 September 2017

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

core

Esse repositório pode ser localizado em .../core/os/ de seu mirror favorito.

core contém pacotes para:

assim como as dependências deles (não necessariamente makedepends).

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.

Nota: Para criar um repositório local com pacotes do core (ou outros repositórios) sem uma conexão internet, veja Pacman tips#Installing packages from a CD/DVD or USB stick

extra

Esse repositório pode ser localizado em .../extra/os/ de seu mirror 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 .../comunidade/os/ de seu mirror 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 mirror 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).

Para mais informações, veja Multilib.

testing

Atenção: Cuidado ao ativar o repositório testing. Seu sistema pode não funcionar adequadamente ao realizar uma atualização. Apenas usuários experientes que sabem como lidar com falhas de sistema em potencial devem usá-lo.

Esse repositório pode ser localizado em .../multilib/os/ de seu mirror 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 /etc/pacman.conf.

Nota: testing não é para 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 da coleção de pacotes do core, seja como crítico de outras formas. Como tal, usuários do testing são incentivados a se inscreverem na lista de discussão arch-dev-public, acompanhar o fórum do repositório testing e a relatar todos os erros.
Warning: Se você habilitar testing, também deve habilitar community-testing. Se você habilitar qualquer outro repositório de teste listado nas subseções a seguir, você também deve habilitar ambos testing e community-testing.

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 a versão mais recente do ambiente gráfico do GNOME, antes de ser movido para o repositório principal de teste testing.

Para habilitá-lo, adicione as seguintes linhas ao /etc/pacman.conf:

[gnome-unstable]
Include = /etc/pacman.d/mirrorlist

A entrada gnome-unstable deve estar primeiro na lista de repositórios (i.e., acima 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 Bugzilla 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:

[kde-unstable]
Include = /etc/pacman.d/mirrorlist

A entrada kde-unstable deve estar primeiro na lista de repositórios (i.e., 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:

  1. Remover (comentar) eles do /etc/pacman.conf
  2. Realizar um # pacman -Syuu para "retroceder" suas atualizações para esses repositórios.

O segundo item é opcional, mas tenha-o em mente que cas você tenha algum problema.

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.