Nonfree applications package guidelines (Português)

From ArchWiki
Jump to: navigation, search
Diretrizes de criação de pacotes

CLRCrossEclipseFree PascalGNOMEGoHaskellJavaKDEKernelLispMinGWNode.jsNonfreeOCamlPerlPHPPythonRRubyVCSWebWine

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:

  1. É melhor oferecer suporte a um software que pertence a todos nós do que um software que pertence a uma empresa
  2. É melhor oferecer suporte a um software que é mantido ativamente
  3. É 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 conversão de nomenclatura estabelecida (por exemplo, não crie algo como gish-hbAUR[link quebrado: archived in aur-mirror] quando já houver aquaria-hibAUR, penumbra-overture-hibAUR e uplink-hibAUR). Sempre use o sufixo -bin, a menos que você tenha certeza de que nunca haverá um pacote baseado em código-fonte; seu criador terá que perguntar a você (ou no pior caso TUs) ao pacote órfão existente. ele e os 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 seguintes opções devem ser consideradas:

  • Há apenas uma forma de obter os arquivos
  • O software é distribuído em pacote/instalador
Adicione o arquivo necessário para o vetor sources:
sources=(... "nome-original::file://nome-original")
Desta forma, o link para o arquivo na interface web do AUR será diferente dos nomes dos arquivos incluídos no tarball de origem.
Adicione o seguinte comentário na página do pacote:
Need archive/installer to work.
e explicar os detalhes no vetor de fontes do PKGBUILD.
  • O software é distribuído em um disco compacto
Adicione um script de instalação e um arquivo .install ao conteúdo do pacote, como no pacote tsukihime-enAUR[link quebrado: archived in aur-mirror].
  • Há várias formas de obter arquivos

Copiar arquivos do disco / fazer o download da Internet / obter 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:

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, 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")

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)

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