AUR submission guidelines (Português)

Status de tradução: Esse artigo é uma tradução de AUR submission guidelines. Data da última tradução: 2024-08-29. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.

Os usuários podem compartilhar scripts de PKGBUILD usando o Arch User Repository. Ele não contém nenhum pacote binário, mas permite que os usuários carreguem PKGBUILDs que podem ser baixados por outras pessoas. Estes PKGBUILDs são completamente não oficiais e não foram cuidadosamente avaliados, por isso devem ser usados por sua conta e risco.

Enviando pacotes

Atenção: Antes de tentar enviar um pacote, espera-se que você esteja familiarizado com os Arch Packaging Standards (padrões de empacotamento do Arch) e todos os artigos sob "Artigos relacionados". Verifique cuidadosamente se o que você está enviando está correto. Pacotes que violam as regras podem ser excluídos sem qualquer aviso.

Se você de alguma forma esta incerto sobre um pacote ou o processo de compilação/envio mesmo após ler essa seção duas vezes, envie o PKGBUILD à lista de discussão do AUR, o fórum do AUR nos fóruns do Arch ou peça em nosso canal IRC por uma revisão pública antes de adicioná-lo ao AUR.

Regras de envio

Ao enviar um pacote para o AUR, observe as seguintes regras:

Os PKGBUILDs enviados não devem compilar aplicativos já presentes em qualquer um dos repositórios oficiais binários sob nenhuma circunstância. Verifique a base de dados de pacotes oficial pelo pacote. Se qualquer versão dele existir, não envie o pacote. Se o pacote oficial estiver desatualizado, sinalize-o como tal. Se o pacote oficial está quebrado ou faltando algum recurso, por favor, envie um relatório de erros.

Exceção a esta regra estrita pode ser apenas pacotes que tenham recursos extras habilitados e/ou patches em comparação com os oficiais. Nesta ocasião, o pkgname deve ser diferente para expressar isso. Por exemplo, um pacote para o GNU Screen contendo o patch da barra lateral poderia ser chamado de screen-sidebar. Além disso, o array conflicts=('screen') deve ser usado para evitar conflitos com o pacote oficial.

Verifique no AUR se o pacote já existe. Se ela estiver atualmente atualizada, as alterações podem ser enviadas em um comentário para a atenção do mantenedor. Se não for mantido ou o mantenedor não responder, o pacote poderá ser adotado e atualizado conforme necessário. Não crie pacotes duplicados.

Certifique-se de que o pacote que você deseja enviar é útil. Alguém mais vai querer usar este pacote? É extremamente especializado? Se mais do que algumas pessoas acham este pacote útil, é apropriado para envio.

O AUR e os repositórios oficiais são destinados a pacotes que instalam softwares em geral e conteúdo relacionado a softwares, incluindo um ou mais dos seguintes: executável(is); arquivo(s) de configuração; documentação online ou offline para software específico ou a distribuição do Arch Linux como um todo; mídia destinada a ser usada diretamente pelo software.

Não use replaces em um PKGBUILD no AUR a menos que o pacote seja renomeado, por exemplo, quando Ethereal se tornou Wireshark. Se o pacote for uma versão alternativa de um pacote já existente, use conflicts (e provides se esse pacote for requerido por outras pessoas). A principal diferença é: após a sincronização (-Sy), o pacman imediatamente deseja substituir um pacote 'ofensivo' instalado ao encontrar um pacote com o replaces correspondente em qualquer lugar em seus repositórios; o conflicts, por outro lado, só é avaliado na instalação do pacote, que geralmente é o comportamento desejado, porque é menos invasivo.

Pacotes que compilam a partir de um sistema de versão de controle e não são atrelados a uma versão específica precisam ter um sufixo apropriado, -git para git e assim por diantes. Veja Diretrizes de pacotes VCS#Nomenclatura de pacote for a full list.

Pacotes que usam deliverables pré-compilados quando os fontes estão disponíveis, devem usar o sufixo -bin. Uma exceção a isso com Java. O AUR não deve conter o tarball binário criado pelo makepkg, nem deve conter a lista de arquivos.

Pacotes que compilam a partir do código-fonte usando uma versão específica não usam um sufixo.

Por favor, adicione uma linha de comentário no topo do arquivo PKGBUILD contendo informações sobre os atuais mantenedores e contribuidores anteriores, respeitando o seguinte formato. Lembre-se de disfarçar o seu e-mail para proteger contra spam. Linhas adicionais são opcionais.

Nota: O uso de ofuscação em se tratando de endereços de e-mail dificulta pessoas a entrarem em contato com você.

Se você está assumindo o papel de mantenedor para um PKGBUILD existente, adicione seu nome ao topo desta forma

# Maintainer: Seu Nome <endereço at domínio dot tld>

Se houver mantenedores antigos, liste-os como contribuidores. O mesmo se aplica para quem enviou o pacote, se não foi você. Se você é um comantenedor, adicione os nome de outros mantenedores atuais também.

# Maintainer: Seu Nome <endereço at domínio dot tld>
# Maintainer: Nome do Outro Mantenedor <endereço at domínio dot tld>
# Contributor: Nome do Mantenedor Anterior <endereço at domínio dot tld>
# Contributor: Nome do Criador do Pacote <endereço at domínio dot tld>

Autenticação

Para acesso de escrita para o AUR, você precisar ter um par de chaves SSH. O conteúdo da chave pública precisa ser copiada para seu perfil em Minha conta e a chave privada correspondente configurada para o endereço aur.archlinux.org. Por exemplo:

~/.ssh/config

Host aur.archlinux.org
  IdentityFile ~/.ssh/aur
  User aur

Você deve criar um novo par de chaves em vez de usar um existente, de forma que você possa seletivamente revogar as chaves caso algo aconteça:

$ ssh-keygen -f ~/.ssh/aur

Dica: Você pode adicionar múltiplas chaves públicas ao seu perfil separando-as com uma nova linha no campo de entrada.

Criando repositórios de pacote

Se você está criando um novo pacote do zero, estabeleça um repositório Git local e um remoto no AUR clonando o pkgbase desejado. Se o pacote ainda não existir, o seguinte aviso é esperado:

$ git -c init.defaultbranch=master clone ssh://aur@aur.archlinux.org/pkgbase.git

Cloning into 'pkgbase'...
warning: You appear to have cloned an empty repository.
Checking connectivity... done.

Nota: O repositório não estará vazio, se pkgbase corresponde a um pacote excluído.

Se você já tem um pacote, inicialize-o como um repositório Git, se ainda não for um:

$ git -c init.defaultBranch=master init

e adicione um remoto do AUR:

$ git remote add rótulo ssh://aur@aur.archlinux.org/pkgbase.git

Então, faça um fetch deste remoto para inicializá-lo no AUR.

Nota: Use pull e rebase para resolver conflitos se o pkgbase corresponder a um pacote excluído.

Publicando novo conteúdo de pacote

Atenção: Seus commits terão como autor seu nome e endereço de e-mail Git globais. É muito difícil de alterar commits após você realizar o push (FS#45425). Se você deseja fazer o push para o AUR sob credenciais diferentes, você pode alterá-los por pacote com git config user.name "..." e git config user.email "...".

Ao lançar uma nova versão do software empacotado, atualize as variáveis pkgver ou pkgrel para notificar todos os usuários que uma atualização é necessária. Não atualize esses valores se apenas pequenas alterações no PKGBUILD, como a correção de um erro de digitação, estiverem sendo publicadas.

Não meramente faça commits de atualizações de pkgver para pacotes VCS. Eles não são considerados desatualizados quando o upstream tem novos commits. Só faça um novo commit quando outras alterações forem introduzidas, tal como alteração no processo de compilação.

Lembre-se de gerar .SRCINFO sempre que os metadados do PKGBUILD forem alterados, como as atualizações do pkgver(); caso contrário, o AUR não mostrará números de versão atualizados.

Para enviar ou atualizar um pacote, adicione pelo menos o PKGBUILD e .SRCINFO, e quaisquer arquivos auxiliares novos ou modificados (tal como arquivos .install ou arquivos fontes locais, como patches; Faça commit deles com uma mensagem de commit significativa e, finalmente, faça um push das alterações para o AUR.

Por exemplo:

$ makepkg --printsrcinfo > .SRCINFO
$ git add PKGBUILD .SRCINFO
$ git commit -m "mensagem útil de commit"
$ git push

Nota:

Se o .SRCINFO não foi incluído no seu último commit, adicione-o alterando seu último commit com git commit --amend de forma que o AUR permita seu push.
O AUR só permite fazer push para o branch master. Se seu branch local tiver outro nome, renomeie-o e faça o push novamente.

Dica: Para manter o diretório de trabalho e os commits o mais limpo possível, crie um gitignore(5) que exclua todos os arquivos e adicione forçadamente os arquivos conforme necessário.

Mantendo pacotes

Verifique os feedback e comentários de outros usuários e tente incorporar quaisquer melhorias que eles sugerirem; considere isso um processo de aprendizado!
Por favor, não envie um comentário contendo a versão toda vez que você atualizar o pacote. Isso deixa a seção de comentário usável para o conteúdo valioso mencionado acima.
Por favor, não apenas envie e depois esqueça dos pacotes! É trabalho do mantenedor manter o pacote, verificando atualizações e melhorando o PKGBUILD.
Se você não deseja continuar mantendo o pacote por algum motivo, basta tornar órfão o pacote usando a interface web AUR e/ou publique uma mensagem na Lista de Discussão do AUR. Se todos os mantenedores de um pacote AUR o abandonarem, ele se tornará um pacote "órfão".
Automação é uma ferramenta valiosa para mantenedores, mas ela não pode substituir a intervenção manual (por exemplo, projetos pode alterar licença, adicionar ou remover dependências e outras alterações notáveis mesmo para lançamentos "menores"). Atualizações automatizadas de PKGBUILD são usadas a seu próprio risco e quaisquer contas com defeito e seus pacotes poderão ser removidos sem aviso prévio.

Requisições

As requisições de exclusão, de mesclagem e de tornar órfão podem ser criadas clicando no link "Enviar requisições" em "Ações do pacote" no lado direito. Isso despacha e-mails de notificação para o mantenedor do pacote atual e para a lista de discussão aur-requests para discussão. Os Mantenedores de Pacote aceitarão ou rejeitarão a requisição.

Exclusão

Solicitação para deslistar um pkgbase do AUR. É necessária uma breve nota explicando o motivo da exclusão, bem como detalhes justificadores (como quando um pacote é fornecido por outro pacote, se você é o mantenedor, ele é renomeado e o proprietário original concorda, etc).

Nota:

Não é suficiente explicar por que um pacote pode ser excluído apenas em seus comentários: assim que o mantenedor do pacote entra em ação, o único lugar onde tal informação pode ser obtida é na lista de discussão aur-requests.
Solicitações de exclusão podem ser rejeitadas; nesse caso, se você for o mantenedor, provavelmente será aconselhado a abandonar o pacote para permitir a adoção por outro mantenedor.
Depois que um pacote é "excluído", seu repositório git permanece disponível para clonagem.

Mesclagem

Solicitação para excluir um pkgbase e transferir seus votos e comentários para outro pkgbase. O nome do pacote no qual será mesclado é obrigatório.

Nota: Isso não tem nada a ver com git merge ou solicitações de mesclagem do GitLab.

Tornar órfão

Solicitação para que um pkgbase seja retirado do mantenedor atual (disown, como usado em inglês). Estas solicitações serão atendidas após duas semanas se o atual mantenedor não reagir. A exceção é se um pacote foi sinalizado como desatualizado há pelo menos 180 dias; solicitações para tornar órfão são então automaticamente aceitas.