Package Maintainer guidelines (Português)

Status de tradução:
Esse artigo é uma tradução de
Package Maintainer guidelines
. Data da última tradução: 2023-12-27. Você pode ajudar a sincronizar a tradução, se houver
alterações
na versão em inglês.
Artigos relacionados
Arch User Repository
DeveloperWiki:How to be a packager
DeveloperWiki:Building in a clean chroot
GnuPG
OpenPGP
O
Mantenedores de Pacote
, ou Package Maintainers, são membros de uma equipe do Arch Linux encarregada de manter o AUR funcionando. Ele/Ela mantém pacotes populares (
comunicando-se com o
upstream
e enviando-o patches quando necessário
) e vota em assuntos administrativos. Um Mantenedor de Pacote é eleito de membros ativos da comunidade pelos atuais Mantenedores de Pacote em um processo democrático. Mantenedores de Pacote são os únicos membros que têm a última palavra na direção do AUR.
Os Mantenedores de Pacote são governados usando as
Package Maintainer bylaws
("Estatuto dos Mantenedores de Pacote")
Lista de tarefas para novos Mantenedores de Pacote
Ler este artigo de wiki por completo.
Ler as
Package Maintainer Bylaws
.
Certificar-se de que os detalhes da sua conta no
AUR
estejam atualizados.
Pedir que um de seus patrocinadores (
sponsors
) lhe dê o status de Mantenedor de Pacote no AUR.
Lembrar um
bureaucrat
de adicionar sua conta wiki ao grupo Arch Linux Package Maintainers
Lembrar um
administrador do BBS
de alterar sua conta nos fóruns.
Pedir a um de seus patrocinadores as chaves de
#archlinux-staff
e
#archlinux-packaging
e participar nos canais (isso não é obrigatório, mas é uma ótima forma de conhecer partes da equipe e colaborar).
Se você precisar de um bouncer, peça ao heftig por um convite de
Matrix
.
Se você quiser uma manta de
@archlinux/package-maintainer/
nome-de-usuário
, peça aos nossos
contatos de grupos
para obter uma.
Pedir a um de seus patrocinadores para criar um ticket no
rastreador de problemas do repositório de infraestrutura
(usando o modelo
Onboarding
) e forneça-os com as seguintes informações:
Uma chave pública SSH. Se você não possuir uma, siga
SSH keys#Generating an SSH key pair
para criar uma.
Um nome de usuário que será usado para sua conta SSO e para seu endereço de e-mail
@archlinux.org
(a ser criado).
Seu nome completo.
Seu endereço de e-mail (pessoal) e um ID de chave pública PGP válido para ele, que será usado para fornecer a senha inicial da interface do desenvolvedor (archweb) para você e que será vinculado a sua conta SSO (a ser criada).
Se seu endereço de e-mail particular ou
nome-de-usuário
@archlinux.org
(a ser criado) deve ser usado para as listas de e-mail não públicas e ter permissão para postar na lista de discussão
arch-dev-public
.
Definir a senha para seu endereço de e-mail
@archlinux.org
seguindo
DeveloperWiki:Staff Services#Email
.
Criar um par de chaves PGP para
assinatura de pacote
seguindo o fluxo de trabalho
para adicionar uma nova chave de empacotador
(usando seu novo endereço
nome-de-usuário
@archlinux.org
como uid).
Pedir a um de seus patrocinadores para criar um ticket no
rastreador de problemas do repositório archlinux-keyring
(usando o modelo
New Packager Key
) para ter sua chave PGP assinada por (pelo menos) três principais detentores de chaves.
Instalar o pacote
devtools
.
Configurar sua chave privada ssh
para os servidores
orion.archlinux.org
e
repos.archlinux.org
.
Testar a conexão SSH para
nome-de-usuário
@orion.archlinux.org
(assim que você tiver permissões).
Começar a contribuir!
O Mantenedor de Pacote e o AUR
Os Mantenedores de Pacote deveriam também fazer um esforço para verificar o envio de pacotes no
AUR
por códigos maliciosos e o correto seguimento dos padrões dos PKGBUILD. Em cerca de 80% dos casos, os PKGBUILDs no AUR são muito simples e podem ter rapidamente verificadas a sanidade e os códigos maliciosos pela equipe de Mantenedores de Pacote.
Os Mantenedores de Pacote devem também verificar os PKGBUILDs por pequenos erros, sugerir correções e melhoras. O Mantenedor de Pacote deve se tentar certificar-se de que todos os pacotes sigam Arch Packaging Guidelines/Standards (Diretrizes/Padrões de Empacotamento do Arch) e ao fazer isso, compartilhar suas habilidades com outros criadores de pacotes em um esforço em criar um padrão de criação de pacotes por toda a distribuição.
Os Mantenedores de Pacote também estão em uma posição de documentar práticas recomendadas.
Reescrevendo histórico Git
Em alguns casos, é necessário reescrever o histórico de um repositório do AUR, por exemplo, quando um usuário inadvertidamente usa seu nome legal em um commit publicado. Isso pode ser automatizado com
git-filter-branch(1)
.
Para realizar um push forçado para um novo histórico, encaminhe a variável de ambiente
AUR_OVERWRITE=1
para o
git-push(1)
.
Em detalhes, isso inclui adicionar
SendEnv AUR_OVERWRITE
à sua configuração AUR SSH e definir o env var em seu comando push:
AUR_OVERWRITE=1 git push --force
.
Veja
[1]
para detalhes.
Atenção
É recomendado criar um backup do repositório antes de reescrever o histórico.
Modificar a identidade do committer ou autor
Instale
git-filter-repo
e execute:
$ git-filter-repo --name-callback 'return name.replace(b"
Nome antigo
", b"
Nome novo
")' --email-callback 'return email.replace(b"
antigo@email.com
", b"
novo@email.com
")'
Dica
Se o nome de usuário contiver caracteres especiais, pode ser necessário codificar as strings
name.replace("Bás Ssze".encode("utf-8"), b"novonome")'
Alternativamente, use
git filter-branch --env-filter
com as
variáveis de ambiente
GIT_AUTHOR_NAME
,
GIT_AUTHOR_EMAIL
,
GIT_COMMITTER_NAME
e
GIT_COMMITTER_EMAIL
. Por exemplo:
git filter-branch --env-filter '
if test "$GIT_AUTHOR_EMAIL" = "lepetit@prince.com"; then
  GIT_AUTHOR_EMAIL=user@users.noreply.github.com
fi
if test "$GIT_AUTHOR_NAME" = "Antoine de Saint-Exupéry"; then
  GIT_AUTHOR_NAME=user
fi'
Nota
git-log(1)
só exibe o
author
git por padrão. Use
git log --pretty=fuller
para exibir o
author
e o
committer
.
Lidando com requisições no AUR
This article or section needs expansion.
Reason:
Esta lista está incompleta agora e deve ser expandida. (Discuss in
Talk:Package Maintainer guidelines
)
Os Mantenedores de Pacote devem verificar periodicamente as
requisições
enviadas no AUR. Para isso existem algumas regras genéricas sobre o que verificar para cada tipo de requisição:
Requisição para tornar órfão
verifique se o pedido tem mais de 14 dias (a coluna de data fica vermelha na visão geral) (você não pode aceitá-lo antes disso de qualquer maneira)
verifique se não houve atualização do próprio pacote (commit ou release) feita nos últimos 14 dias
verifique se não houve comentário do mantenedor do pacote no AUR feito nos últimos 14 dias
Se todos os pontos acima forem atendidos, você poderá aceitar a requisição para tornar órfão.
O Mantenedor de Pacote e extra, diretrizes para manutenção de pacotes
Regras para a entrada de pacotes no repositório extra
Um pacote não pode já existir em qualquer um dos repositórios do Arch Linux. você deve tomar os cuidados necessários para se certificar que nenhum outro empacotador está no processo de promoção do mesmo pacote. Veja os comentários do pacote do AUR, leia os últimos títulos de assuntos no
aur-general
, pesquise em
todos os projetos no rastreador de erro
[
link inativo
2024-01-13 ⓘ]
, faça um
grep
no
git-log(1)
e envie uma mensagem rápida para o
canal IRC
privado "packaging".
Wrappers do pacman
, como uma exceção especial, nunca serão permitidos. Se desejar adicionar
auxiliares do AUR
, escreva um e-mail para
arch-dev-public
com a adição proposta e respeite as objeções fornecidas pelos membros da equipe.
The factual accuracy of this article or section is disputed.
Reason:
A regra abaixo é arbitrária e não aplicada na prática. O dois pontos seguintes também precisam ser ajustados. (Discuss in
Talk:Package Maintainer guidelines
)
Somente pacotes "populares" podem entrar no repositório, sendo definido pelo 1% de uso no
pkgstats
ou 10 votos no AUR.
Exceções automáticas a esta regra são:
pacotes de internacionalização (i18n)
pacotes de acessibilidade
drivers
dependências de pacotes que satisfazem a definição de populares, incluindo
makedeps
e
optdeps
pacotes que são parte de uma coleção e têm a intenção de ser distribuídos juntos, fornecendo uma parte da coleção satisfaz a definição de popular
Quaisquer adições não cobertas por nenhum dos critérios acima devem ser propostas na lista de discussão aur-general, explicando o motivo para a dispensa (ex.: pacote renomeado, novo pacote). O acordo de três outros Mantenedores de Pacote é necessário para que o pacote seja aceito na
extra
. Adições propostas por Mantenedores de Pacote com grande número de pacotes "não-populares" provavelmente serão rejeitadas.
Os Mantenedores de Pacote são incentivados a mover os pacotes mantidos do
extra
, se eles tiverem baixo uso. Nenhuma aplicação será necessária, apesar de que a renúncia de pacotes de Mantenedores de Pacote pode ser filtrada antes que ocorra adoção.
É uma boa prática sempre incrementar o
pkgrel
em
1
(em outras palavras, defina o para
n + 1
) ao promover um pacote do AUR. Isso é para facilitar atualizações automáticas para aqueles que já têm o pacote instalado, de forma que eles podem continuar a receber atualizações a partir do canal oficial. Um outro efeito positivo disto é que usuários não são avisados que sua cópia local é mais nova, como é o caso se um empacotador redefinir o
pkgrel
para
1
.
Acessando e atualizando o repositório
Veja o
guia do empacotador
.
Abandonando pacotes
Se um Mantenedor de Pacote não pode ou não quer mais manter um pacote, um aviso deve ser postado na Lista de Discussão do AUR, para que outro mantenedor de pacote possa mantê-lo. Um pacote pode ainda ser abandonado mesmo se nenhum outro Mantenedor de Pacote quiser mantê-lo, mas os Mantenedores de Pacote devem evitar de deixar muitos pacotes soltos (eles não deveriam manter mais do que possam dar conta). Se um pacote se tornou obsoleto ou não é mais usado, ele também pode ser completamente removido.
Se um pacote foi removido completamente, o mesmo pode ser enviado novamente (do zero) para o AUR, onde um usuário normal pode manter o pacote ao invés de um Mantenedor de Pacote.
Movendo pacotes do AUR para extra
Siga os procedimentos normais para adição de um pacote ao
extra
usando as instruções do
guia do empacotador
, mas lembre-se de remover o pacote correspondente do AUR!
Movendo pacotes do extra para AUR
Remova o pacote usando as instruções do
guia do empacotador
e envie o seu tarball fonte para o AUR.
Movendo pacotes do extra-testing para extra
Mova o pacote do repositório
extra-testing
para o repositório
extra
usando as instruções do
guia do empacotador
.
Compilação remota no build.archlinux.org
Atenção
Os procedimentos a seguir invalidam o modelo Web Of Trust: um usuário com acesso root ao PKGBUILD.com poderia alterar o pacote e/ou a assinatura antes de publicá-lo.
Mantenedor de Pacote e Desenvolvedores podem se conectar ao build.archlinux.org via SSH para, entre outros, criar pacotes usando o devtools.
Isso tem diversas vantagens sobre a configuração local:
Compilações são rápidas e a velocidade de rede é alta.
O ambiente precisa ser configurado apenas uma vez.
Seu sistema local não precisa ser Arch Linux.
O processo é semelhante ao de uma configuração local com devtools. Seu GnuPG privado é necessário para assinar, mas você não quer enviá-lo por razões óbvias de segurança. Como tal, você precisará encaminhar o soquete de agente do GnuPG de sua máquina local para o servidor: isso permitirá que você assine pacotes no servidor de compilação sem comunicar sua chave. Isso também significa que precisamos desabilitar o agente no servidor antes de podermos executar qualquer coisa.
Primeiro, conecte-se ao servidor de compilação e desabilite-o:
$ ssh build.archlinux.org
$ systemctl --user mask gpg-agent.service
Certifique-se de que o gpg-agent não esteja em execução (
systemctl --user stop gpg-agent.service
). Neste ponto, certifique-se de que não existem soquetes na pasta apontada por
gpgconf --list-dir socketdir
. Em caso afirmativo, remova-os ou efetue o logout e novamente.
Se você tem um $GNUPGHOME personalizado (por exemplo, para movê-lo para
~/.config/gnupg
), você precisará desmarcar isso, pois não é possível no gnupg definir o homedir sem configurar o socketdir.
No servidor de compilação,
StreamLocalBindUnlink yes
está definido no
sshd_config
, então remover os soquetes manualmente no logout não é necessário.
Enquanto as chaves privadas PGP permanecem em sua máquina local, as chaves públicas
devem
estar no servidor de compilação. Exportar sua chave público para o servidor de compilação, por exemplo da sua máquina local
$ scp ~/.gnupg/pubring.gpg build.archlinux.org:~/.gnupg/pubring.gpg
O SSH é necessário para fazer
checkout
e
commit
no repositório Git. Você pode configurar um novo par de chaves SSH no servidor (é altamente desencorajado colocar sua chave privada local no servidor por motivos de segurança) ou reutilizar as chaves locais por meio do encaminhamento de soquete. Se você optar por este último, certifique-se de desabilitar o ssh-agent no servidor de compilação se você o habilitou anteriormente (ele não está em execução por padrão).
Configure seu ambiente de compilação no servidor de compilação:
~/.makepkg.conf
PACKAGER="John Doe <john@doe.example>"
## Opcional
PKGDEST="/home/johndoe/packages"
SRCDEST="/home/johndoe/sources"
SRCPKGDEST="/home/johndoe/srcpackages"
LOGDEST="/home/johndoe/logs"
## Se sua chave PGP não é a padrão, especifique a impressão digital correta:
GPGKEY="ABCD1234..."
Atenção
Encaminhar seu soquete gpg-agent para uma máquina remota possibilita que qualquer pessoa com acesso root a esse sistema use suas credenciais GPG desbloqueadas. Para contornar esse problema, precisamos desabilitar o armazenamento em cache da frase secreta.
Desabilite o cache de senha com as seguintes configurações:
gpg-agent.conf
default-cache-ttl 0
max-cache-ttl 0
Como desejaremos manter nosso agente GPG normal em execução com suas configurações atuais, executaremos outro agente GPG dedicado à tarefa em questão. Crie uma pasta
~/.gnupg-archlinux
e crie uma ligação simbólica de
~/.gnupg
, exceto
~/.gnupg/gpg-agent.conf
. Configure o novo agente GPG:
~/.gnupg-archlinux
extra-socket /home/doe/.gnupg-archlinux/S.gpg-agent.extra
default-cache-ttl 0
max-cache-ttl 0
pinentry-program /usr/bin/pinentry-gtk-2
O
gpg-agent-extra.socket
será encaminhado para build.archlinux.org.
Inicie o agente dedicado com:
$ gpg-agent --homedir ~/.gnupg-archlinux --daemon
Conecte-se com:
$ ssh -R $REMOTE_SSH_AUTH_SOCK:$SSH_AUTH_SOCK -R /run/user/$REMOTE_UID/gnupg/S.gpg-agent:/home/doe/.gnupg-archlinux/S.gpg-agent.extra build.archlinux.org
ou, se estiver usando GnuPG como seu agente SSH, com:
$ ssh -R /run/user/
REMOTE_UID
/gnupg/S.gpg-agent.ssh:/run/user/
LOCAL_UID
/gnupg/S.gpg-agent.ssh -R /run/user/
REMOTE_UID
/gnupg/S.gpg-agent:/home/doe/.gnupg-archlinux/S.gpg-agent.extra build.archlinux.org
Substitua
REMOTE_UID
e
LOCAL_UID
pelo seu identificador de usuário como retornado por
id -u
no servidor de compilação e localmente, respectivamente.
Se estiver usando ssh-agent, substitua
REMOTE_SSH_AUTH_SOCK
pelo caminho para o soquete SSH no host remoto (pode ser qualquer coisa).
Você pode tornar o encaminhamento permanente para esse host. Por exemplo, com gpg-agent.ssh:
~/.ssh/config
Host build.archlinux.org
  RemoteForward /run/user/
REMOTE_UID
/gnupg/S.gpg-agent /run/user/
LOCAL_UID
/gnupg/S.gpg-agent.extra
  RemoteForward /run/user/
REMOTE_UID
/gnupg/S.gpg-agent.ssh /run/user/
LOCAL_UID
/gnupg/S.gpg-agent.ssh
Novamente, substitua
REMOTE_UID
com o UID do servidor de compilação.
A partir de então, o procedimento deve ser exatamente igual a uma compilação local:
$ ssh build.archlinux.org
$ pkgctl repo clone existing-package
$ ...
Nota
pinentry-curses pode não funcionar com encaminhamento de soquete. Se ele falhar para você, tente usar um pinentry diferente.
Lista de TODO na renúncia de um Mantenedor de Pacote
Quando um Mantenedor de Pacote renuncia, a seguinte lista tem que ser seguida -- essas etapas não se aplicam quando um Mantenedor de Pacote renuncia sendo ainda um desenvolvedor.
Todos os pacotes empacotados pelo TU retirado devem ser resignados (portanto, recompilados). Pacotes empacotados pelo retirado podem ser localizados no Archweb
https://archlinux.org/packages/?sort=&q=&empacotador=$empacotador&flagged=
, sendo empacotador o nome de usuário no Archweb.
A conta do renunciado deve ser desabilitada no Archweb e adicionada ao grupo "Retired Package maintainers". O retirado deve ser removido dos "Package Maintainers" e as permissões de repositório devem ser reduzidas a zero.
O acesso shell a nossos servidores deve ser desabilitado. (especialmente repos.archlinux.org, pkgbuild.com)
A chave GPG deve ser removida e um novo pacote
archlinux-keyring
deve ser enviado para os repositórios. Crie um relatório de erro no projeto do chaveiro para remover as chaves dos Mantenedores de Pacote retirados.
Remova o grupo de Mantenedor de Pacote de suas contas AUR.
Um
bureaucrat
deve remover sua conta wiki do grupo Arch Linux Package Maintainers.
Um
administrador do BBS
deve mudar sua conta nos fóruns.