Package Maintainer guidelines (Português) - ArchWiki

Jump to content
From ArchWiki
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:Index#Packaging Guidelines
- 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

1. Ler este artigo de wiki por completo.
2. Ler as Package Maintainer Bylaws.
3. Certificar-se de que os detalhes da sua conta no AUR estejam atualizados.
4. Pedir que um de seus patrocinadores (sponsors) lhe dê o status de Mantenedor de Pacote no AUR.
5. Lembrar um bureaucrat de adicionar sua conta wiki ao grupo Arch Linux Package Maintainers
6. Lembrar um administrador do BBS de alterar sua conta nos fóruns.
7. 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.
8. 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.
9. Definir a senha para seu endereço de e-mail `@archlinux.org` seguindo DeveloperWiki:Staff Services#Email.
10. 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).
11. 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.
12. Instalar o pacote devtools.
13. Configurar sua chave privada ssh para os servidores `orion.archlinux.org` e `repos.archlinux.org`.
14. Testar a conexão SSH para `nome-de-usuário@orion.archlinux.org` (assim que você tiver permissões).
15. 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, 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.

1. 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.
2. 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.
3. O acesso shell a nossos servidores deve ser desabilitado. (especialmente repos.archlinux.org, pkgbuild.com)
4. 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.
5. Remova o grupo de Mantenedor de Pacote de suas contas AUR.
6. Um bureaucrat deve remover sua conta wiki do grupo Arch Linux Package Maintainers.
7. Um administrador do BBS deve mudar sua conta nos fóruns.

Category:

- Package development (Português)

Hidden categories:

- Pages or sections flagged with Template:Expansion
- Pages or sections flagged with Template:Accuracy