Difference between revisions of "Nonfree applications package guidelines (Português)"

From ArchWiki
Jump to: navigation, search
(Mantenha simples: Translation)
(Nomenclatura de pacotes: Translation)
Line 39: Line 39:
  
 
== Nomenclatura de pacotes ==
 
== Nomenclatura de pacotes ==
Before choosing a name on your own, search in AUR for existing versions of the software you want to package. Try to use established naming conversion (e.g. do not create something like {{AUR|gish-hb}}{{Broken package link|{{aur-mirror|gish-hb}}}} when there are already {{AUR|aquaria-hib}}, {{AUR|penumbra-overture-hib}} and {{AUR|uplink-hib}}). Use suffix {{Ic|-bin}} '''always''' unless you are sure there will never be a source-based package—its creator would have to ask you (or in worst case TUs) to orphan existing package for him and you both will end up with PKGBUILDs cluttered with additional {{Ic|replaces}} and {{Ic|conflicts}}.
+
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 {{AUR|gish-hb}} quando já houver {{AUR|aquaria-hib}}, {{AUR|penumbra-overture-hib}} e {{AUR|uplink-hib}}). '''Sempre''' use o sufixo {{Ic|-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 {{Ic|replaces}} e {{Ic|conflicts}} adicionais.
  
 
== Colocação de arquivos ==
 
== Colocação de arquivos ==

Revision as of 00:19, 18 June 2018

Tango-preferences-desktop-locale.pngEsse artigo ou seção precisa de tradução.Tango-preferences-desktop-locale.png

Notas: Este artigo está sendo traduzido. (Discuta na Talk:Nonfree applications package guidelines (Português)#)
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 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

Again, analyze existing packages (if present) and decide whether or not you want to conflict with them. Do not place things under /opt unless you want to use some ugly hacks like giving ownership root:games to the package directory (so users in group games running the game can write files in the game's own folder).

Arquivos em falta

For most commercial games there is no way to (legally) download game files, which is the preferable way to get them for normal packages. Even when it is possible to download files after providing a password (like with all Humble Indie Bundle games) asking user for this password and downloading somewhere in build function is not recommended for a variety of reasons (for example, the user may have no Internet access but have all files downloaded and stored locally). The following options should be considered:

  • There is only one way to obtain files
  • Software is distributed in archive/installer
Add the required file to sources array:
sources=(... "originalname::file://originalname")
This way the link to file in AUR web interface will look different from names of files included in source tarball.
Add following comment on package page:
Need archive/installer to work.
and explain the details in PKGBUILD source.
  • Software is distributed on compact-disk
Add installer script and .install file to package contents, like in package tsukihime-enAUR[broken link: archived in aur-mirror].
  • There are several ways to obtain files

Copying files from disk / downloading from Net / getting from archive during build phase may look like a good idea but it is not recommended because it limits the user's possibilities and makes package installation interactive (which is generally discouraged and just annoying). Again, a good installer script and .install file can work instead.

Few examples of various strategies for obtaining files required for package:

Tópicos avançados

DLAGENTS personalizados

Some software authors aggressively protect their software from automatic downloading: ban certain "User-Agent" strings, create temporary links to files etc. You can still conveniently download this files by using DLAGENTS variable in PKGBUILD (see makepkg.conf(5)). This is used by some packages in official repositories, for example ttf-baekmuk.

Please pay attention, if you want to have a customized user-agent string, if the latter contains spaces, parentheses, or slashes in it (or actually anything that can break parsing), this will not work. There's no workaround, this is the nature of arrays in bash and the way DLAGENTS was designed to be consumed in makepkg. The following example will thus not work:

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

Shorten it to the following which is working:

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

And following allows to extract temporary link to file from download page:

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

Desempacotamento

Many proprietary programs are shipped in nasty installers which sometimes do not even run in Wine. Following tools may be of some help:

  • unzip and unrar unpack executable SFX archives, based on this formats
  • cabextract can unpack most .cab files (including ones with .exe extension)
  • unshield can extract CAB files from InstallShield installers
  • p7zip unpacks not only many archive formats but also NSIS-based .exe installers
    • it even can extract single sections from common PE (.exe & .dll) files!
  • upx is sometimes used to encrypt above-listed executables and can be used for decryption as well
  • innoextract can unpack .exe installers created with Inno Setup (used for example by GOG.com games)

In order to determine exact type of file run file file_of_unknown_type.

Obtendo ícones para arquivos .desktop

Proprietary software often have no separate icon files, so there is nothing to use in .desktop file creation. Happily .ico files can be easily extracted from executables with programs from icoutils package. You can even do it on fly during build phase, for example:

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