Nonfree applications package guidelines (Português)

Status de tradução: Esse artigo é uma tradução de Nonfree applications package guidelines. Data da última tradução: 2019-11-11. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.

Diretrizes de pacotes do Arch

32-bit – CLR – CMake – Cross – DKMS – Eclipse – Electron – Fonte – Free Pascal – GNOME – Go – Haskell – Java – KDE – Kernel – Lisp – Meson – MinGW – Node.js – Nonfree – OCaml – Perl – PHP – Python – R – Ruby – Rust – VCS – Web – Wine

Para muitos aplicativos (a maioria dos quais são do Windows), não há fontes nem tarballs disponíveis. Muitos desses aplicativos não podem ser distribuídos livremente devido a restrições de licença e/ou falta de meios legais para obter o instalador sem cobrança de taxa. Tal software obviamente não pode ser incluído nos repositórios oficiais mas devido à natureza do AUR ainda é possível privadamente compilar pacotes para ele, gerenciável com pacman.

Nota: Todas as informações aqui são agnósticos a pacotes. Para informações específicas para a maioria dos softwares não livres, veja Diretrizes de pacotes Wine.

Motivo

Existem vários motivos para empacotar softwares não empacotáveis:

Simplificação de processo de instalação/remoção

Isso é aplicável até mesmo aos aplicativos mais simples, que consistem em um único script a ser instalado em /usr/bin. Em vez de executar:

$ chmod +x nome-de-arquivo

$ chown root:root nome-de-arquivo

# cp filename /usr/bin/

você pode digitar

$ makepkg -i

A maioria dos aplicativos não livres é obviamente muito mais complicada, mas o fardo de baixar um arquivo/instalador de uma página inicial (muitas vezes cheia de propaganda), descompactá-lo/descriptografá-lo, escrever scripts de lançadores estereotipados e realizar outras tarefas semelhantes pode ser efetivamente facilitadas por um script de empacotamento bem escrito.

Usando capacidades do pacman

A capacidade de rastrear estado, executar atualizações automáticas de qualquer software instalado, determinar a propriedade de cada arquivo e armazenar pacotes compactados em um cache bem organizado é o que torna as distribuições GNU/Linux tão poderosas.

Compartilhamento de código e conhecimento

É mais simples aplicar ajustes, corrigir bugs e procurar/fornecer ajuda em um único local público, como o AUR, em vez de enviar patches para desenvolvedores proprietários que podem ter interrompido o suporte ou fazer perguntas vagas em fóruns de propósito geral.

Regras comuns

Evite software não livre quando possível

Sim, é melhor deixar este guia e passar algum tempo procurando (ou talvez até criando) alternativas para um aplicativo que você queria empacotar porque:

É melhor oferecer suporte a um software que pertence a todos nós do que um software que pertence a uma empresa
É melhor oferecer suporte a um software que é mantido ativamente
É melhor oferecer suporte a um software que pode ser consertado se apenas uma pessoa, em milhões, se importar o suficiente

Use variantes de código aberto quando possível

Muitos jogos comerciais (alguns estão listados neste Wiki) possuem mecanismos de código aberto e muitos jogos antigos podem ser reproduzidos com emuladores como ScummVM. O uso de mecanismos de software livre junto com os recursos originais do jogo oferece aos usuários acesso a correções de erros e elimina vários problemas causados por pacotes binários.

Mantenha simples

Se o empacotamento de algum programa exigir mais esforço e hacks do que comprar e usar a versão original - faça a coisa mais simples, isso é Arch!

Nomenclatura de pacotes

Antes de escolher um nome, pesquise no AUR as versões existentes do software que você deseja empacotar. Tente usar uma convenções de nomenclatura estabelecida (por exemplo, não crie algo como gish-hb^AUR^{[link quebrado: package not found]} quando já houverem pacotes para aquaria-hib^AUR, penumbra-overture-hib^AUR^{[link quebrado: package not found]} e uplink-hib^AUR). Sempre use o sufixo -bin, a menos que você tenha certeza de que nunca haverá um pacote baseado em código-fonte – o criador do pacote teria que pedir a você (ou, no pior caso, um TUs) que tornasse órfão (isto é, abandonasse) o pacote existente para que ele e vocês dois acabarão com PKGBUILDs cheios de replaces e conflicts adicionais.

Colocação de arquivos

Novamente, analise os pacotes existentes (se houver) e decida se deseja ou não entrar em conflito com eles. Não coloque coisas em /opt, a menos que você queira usar alguns hacks feios como dar a propriedade root:games ao diretório do pacote (para que os usuários do grupo games o jogo pode gravar arquivos na própria pasta do jogo).

Arquivos em falta

Para a maioria dos jogos comerciais, não há como (legalmente) baixar arquivos de jogos, o que é a maneira preferida de obtê-los para pacotes normais. Mesmo quando é possível baixar arquivos após fornecer uma senha (como com todos os jogos do Humble Indie Bundle) solicitando ao usuário essa senha e fazendo o download em alguma parte da função build, não é recomendado por várias razões (por exemplo, o usuário pode não ter acesso à Internet, mas ter todos os arquivos baixados e armazenados localmente).

As subseções abaixo fornecem recomendações para algumas situações que você pode encontrar.

Os arquivos só podem ser obtidos em um pacote/instalador distribuído

O software só está disponível através desse arquivo de pacote/instalador, que deve ser obtido para obter os arquivos em falta.

Adicione o pacote/instalador necessário a um vetor source, renomeando o nome do arquivo de origem para que o link da origem na interface web do AUR seja diferente dos nomes dos arquivos incluídos no tarball de origem:

source=(... "nomeoriginal::local://nomeoriginal")

Adicione também um comentário fixado como o abaixo na página do pacote no AUR e explique os detalhes no PKGBUILD:

Need archive/installer to work.

Esquema a escolher

Caso você use o esquema local:// em um array de fontes, o makepkg se comporta como se nenhum esquema fosse especificado, e o arquivo deve ser colocado manualmente no mesmo diretório que o PKGBUILD.

Caso você use o esquema file://, você pode adicionalmente especificar DLAGENTS para o protocolo file, de forma que ele pode ser obtido em uma forma especial. Veja os exemplos abaixo.

Porém, ainda não há regras claras sobre quais esquemas você deve usar.

Os arquivos só podem ser obtidos em um CD distribuído ou outro tipo de mídia de disco ótico

O software só está disponível através de uma mídia de disco óptico (por exemplo, CD, DVD, Bluray, etc.), que deve ser inserido na unidade de disco ótico para obter os arquivos em falta.

Adicione um script instalador e um arquivo .install ao conteúdo do pacote, como em tsukihime-en^AUR^{[link quebrado: package not found]}.

Os arquivos podem ser obtidos de várias maneiras

Copiar arquivos do disco, fazer o download da internet ou sair do arquivo durante a fase build pode parecer uma boa ideia, mas não é recomendado porque limita as possibilidades do usuário e torna a instalação do pacote interativa (o que geralmente é desencorajado e irritante). Novamente, um bom script de instalação e um arquivo .install podem funcionar.

Alguns exemplos de várias estratégias para obter arquivos necessários para o pacote:

worldofgoo^AUR – dependência em arquivo fornecido por usuário
umineko-en^AUR^{[link quebrado: package not found]} – combinando arquivos de patch livremente disponível e disco compacto fornecido por usuário
worldofgoo-demo^AUR^{[link quebrado: package not found]} – obtenção automática de instalação durante a fase de compilação
ut2004-anthology^AUR^{[link quebrado: package not found]} – pesquisando por disco via pontos de montagem

Tópicos avançados

DLAGENTS personalizados

Alguns autores de software protegem agressivamente seu software contra downloads automáticos: proíbem certas strings "User-Agent", criam links temporários para arquivos, etc. Você ainda pode convenientemente baixar estes arquivos usando a variável DLAGENTS no PKGBUILD (veja makepkg.conf(5)). Isto é usado por alguns pacotes em repositórios oficiais, por exemplo, em versões anteriores do ttf-baekmuk.

Por favor, preste atenção, se você quiser ter uma string user-agent personalizada, se esta contiver espaços, parênteses ou barras (ou, na verdade, qualquer coisa que possa interromper a análise), isso não funcionará. Não há solução alternativa, essa é a natureza de vetores no bash e a maneira como o DLAGENTS foi projetado para ser usado no makepkg. O exemplo a seguir, portanto, não funciona:

DLAGENTS=("http::/usr/bin/curl -A 'Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1)' -fLC - --retry 3 --retry-delay 3 -o %o %u")

Encurte para o seguinte que está funcionando:

DLAGENTS=("http::/usr/bin/curl -A 'Mozilla' -fLC - --retry 3 --retry-delay 3 -o %o %u")

E, a seguir, permita extrair link temporário para o arquivo da página de download:

DLAGENTS=("http::/usr/bin/wget -r -np -nd -H %u")

Para baixar links temporários para arquivos ou passar por um download interativo, é possível analisar a solicitação HTTP usada para criar o link de download final e, em seguida, criar um DLAGENTS que emule isso usando o curl. Veja por exemplo blackmagic-decklink-sdk^AUR^{[link quebrado: package not found]} ou jlink-software-and-documentation^AUR.

Alternativamente, o DLAGENTS pode ser usado para fornecer uma mensagem de erro mais informativa ao usuário quando um arquivo está faltando. Veja, por exemplo, ttf-ms-win10^AUR.

Desempacotamento

Muitos programas proprietários são publicados em instaladores desagradáveis que às vezes nem funcionam no Wine. As seguintes ferramentas podem ajudar:

unzip e unrar descompactam arquivos SFX executáveis, baseados nesses formatos
cabextract pode descompactar a maioria dos arquivos .cab (incluindo aqueles com extensão .exe)
unshield pode extrair arquivos CAB de instaladores do InstallShield
p7zip descompacta não apenas muitos formatos de arquivo, mas também NSIS - instaladores .exe
- ele pode até mesmo extrair seções únicas de arquivos comuns de PE (.exe e .dll)!
upx às vezes é usado para compactar os executáveis listados acima e também pode ser usado para descompactá-los
innoextract pode descompactar instaladores .exe criados com Inno Setup (usado, por exemplo, por jogos GOG.com)
libarchive contém bsdtar, que pode extrair imagens .iso e arquivos .AppImage (que na verdade são iso9660 híbridos autoexecutáveis)

Para determinar o tipo exato de arquivo, execute file arquivo_de_tipo_desconhecido.

Obtendo ícones para arquivos .desktop

O software proprietário geralmente não possui arquivos de ícone separados, portanto, não há nada para usar na criação de arquivos .desktop. Felizmente, .ico arquivos podem ser facilmente extraídos de executáveis com programas do pacote icoutils. Você pode até fazer isso durante a fase build, por exemplo:

$ wrestool -x --output=icon.ico -t14 executable.exe