Jump to content

# AUR submission guidelines (Português)

From ArchWiki
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.

Artigos relacionados

- Padrões de empacotamento do Arch
- Diretrizes de Mantenedor de Pacote

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 `PKGBUILD`s que podem ser baixados por outras pessoas. Estes `PKGBUILD`s 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 `PKGBUILD`s 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.

Categories:

- About Arch (Português)
- Package development (Português)
- Package management (Português)

AUR submission guidelines (Português)
Add topic