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