Difference between revisions of "Arch packaging standards (Português)"

From ArchWiki
Jump to: navigation, search
m (fix categorization)
(Licenças: this section (and the whole article) isn't maintained by the devs, merged it to PKGBUILD#license, see Talk:Arch_packaging_standards#Licenses:_Don.27t_mention_prophetic_new_features_that_have_nothing_to_do_with_packaging_standards)
 
(15 intermediate revisions by 6 users not shown)
Line 2: Line 2:
 
[[Category:Package management (Português)]]
 
[[Category:Package management (Português)]]
 
[[Category:Package development (Português)]]
 
[[Category:Package development (Português)]]
[[en:Arch Packaging Standards]]
+
[[en:Arch packaging standards]]
[[es:Arch Packaging Standards]]
+
[[es:Arch packaging standards]]
 
[[fr:Standard paquetage]]
 
[[fr:Standard paquetage]]
[[it:Arch Packaging Standards]]
+
[[it:Arch packaging standards]]
[[ru:Arch Packaging Standards]]
+
[[ja:Arch パッケージングスタンダード]]
[[sr:Arch Packaging Standards]]
+
[[ru:Arch packaging standards]]
[[zh-CN:Arch Packaging Standards]]
+
[[sr:Arch packaging standards]]
[[zh-TW:Arch Packaging Standards]]
+
[[zh-hans:Arch packaging standards]]
'''Os PKGBUILDs enviados não devem compilar aplicativos que já estejam em quaisquer dos repositórios de binários oficiais em qualquer circunstância. Exceção a esta regra estrita pode ser pacotes que tenha recursos extras habilitados e/ou patches em comparação aos oficiais. Nesta ocasião, o vetor pkgname deve ser diferente.'''
+
[[zh-hant:Arch packaging standards]]
 +
{{Related articles start (Português)}}
 +
{{Related|Creating packages (Português)}}
 +
{{Related|PKGBUILD (Português)}}
 +
{{Related|makepkg (Português)}}
 +
{{Related|Arch Build System (Português)}}
 +
{{Related|Arch User Repository (Português)}}
 +
{{Related articles end}}
  
Ao compilar pacotes para o Arch Linux, '''siga as diretrizes de empacotamento''' abaixo, especialmente a intenção é '''contribuir''' com um novo pacote para o Arch Linux. Você também deveria ler as páginas man do [http://archlinux.org/pacman/PKGBUILD.5.html PKGBUILD] e do [http://archlinux.org/pacman/makepkg.8.html makepkg].
+
Ao compilar pacotes para o Arch Linux, '''siga as diretrizes de empacotamento''' abaixo, especialmente se a intenção é '''contribuir''' com um novo pacote para o Arch Linux. Você também deve ler as páginas de manual do [https://archlinux.org/pacman/PKGBUILD.5.html PKGBUILD] e do [https://archlinux.org/pacman/makepkg.8.html makepkg].
  
 
== Protótipo de PKGBUILD ==
 
== Protótipo de PKGBUILD ==
 +
 
{{bc|1=
 
{{bc|1=
 
# Maintainer: Seu nome <seu-email@domínio.com>
 
# Maintainer: Seu nome <seu-email@domínio.com>
Line 37: Line 45:
 
source=($pkgname-$pkgver.tar.gz)
 
source=($pkgname-$pkgver.tar.gz)
 
noextract=()
 
noextract=()
md5sums=() #gerado com 'makepkg -g'
+
md5sums=() #gerado com updpkgsums
  
 
build() {
 
build() {
   cd "$srcdir/$pkgname-$pkgver"
+
   cd "$pkgname-$pkgver"
  
 
   ./configure --prefix=/usr
 
   ./configure --prefix=/usr
Line 47: Line 55:
  
 
package() {
 
package() {
   cd "$srcdir/$pkgname-$pkgver"
+
   cd "$pkgname-$pkgver"
  
 
   make DESTDIR="$pkgdir/" install
 
   make DESTDIR="$pkgdir/" install
Line 53: Line 61:
 
}}
 
}}
  
Outros protótipos podem ser encontrados em {{ic|/usr/share/pacman}} dos pacotes {{ic|pacman}} e {{ic|abs}}.
+
Outros protótipos podem ser encontrados em {{ic|/usr/share/pacman}} dos pacotes pacman e abs.
  
 
== Etiqueta de pacotes ==
 
== Etiqueta de pacotes ==
  
<ul>
+
* Os pacotes '''jamais''' devem ser instalados em {{ic|/usr/local}}
<li>Os pacotes '''nunca''' devem ser instalados em {{ic|/usr/local}}</li>
+
* '''Não introduza novas variáveis''' no scripts de compilação {{ic|PKGBUILD}}, a menos que o pacote não possa ser compilado sem elas, pois elas podem '''conflitar''' com variáveis usadas pelo próprio makepkg.
<li>
+
* Se uma nova variável for absolutamente necessária, '''prefixe um caractere de sublinhado''' ({{ic|_}}), ex: {{bc|1=_variavelpersonalizada=}}
'''Não introduza novas variáveis''' em
+
* O campo {{ic|packager}} do meta-arquivo do pacote pode ser '''personalizado''' pelo compilador do pacote, modificando a opção apropriada no arquivo {{ic|/etc/makepkg.conf}} ou, alternativamente, sobrescrevendo-o com a criação de um ~/.makepkg.conf
scripts de compilação {{ic|PKGBUILD}}, a menos que o pacote não possa ser compilado sem elas, pois elas
+
* Todas as mensagens importantes devem ser exibidas durante a instalação usando um '''arquivo .install'''. Por exemplo, se um pacote precisa de configurações extras para funcionar, as direções devem ser incluídas neste arquivo.
podem '''conflitar''' com variáveis usadas pelo próprio makepkg.
+
* '''Dependências''' são os erros mais comuns de empacotamento. Por favor, invista um tempo em verificá-las cuidadosamente, por exemplo executando {{ic|ldd}} em executáveis dinâmicos, verificando ferramentas necessárias por scripts ou olhando documentação do software. O utilitário [[namcap]] pode lhe ajudar neste assunto. Essa ferramenta pode analisar ambos PKGBUILD e o tarball de pacote resultante e vai avisar você sobre permissões erradas, dependências em falta, dependências redundantes e outros erros comuns.
 
+
* Quaisquer '''dependências opcionais''' que não são necessárias para executar o pacote ou que faça-o funcionar, não devem ser incluídas no vetor '''depends'''; em vez disso, a informação deve ser adicionada ao vetor '''optdepends''':
Se uma nova variável for absolutamente necessária,
+
:{{bc|<nowiki>
'''acrescente, antes da variável, um underscore''' ({{ic|_}}), ex:
 
{{bc|1=_variavelpersonalizada=}}
 
 
 
O AUR não consegue detectar o uso de variáveis personalizadas e, portanto, não consegue usar em substituições. Isso normalmente pode ser visto em vertores de fontes. Ex:
 
{{bc|<nowiki>http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2</nowiki>}}
 
Tal situação acaba com a funcionalidade efetiva do AUR.
 
</li>
 
 
 
<li>
 
'''Evite''' usar {{ic|/usr/libexec/}} para qualquer coisa. Ao invés disso, use {{ic|/usr/lib/${pkgname}/}}.
 
</li>
 
<li>
 
O campo {{ic|packager}} do meta arquivo do pacote pode ser '''personalizado''' para compilador do pacote, modificando a opção apropriada no arquivo {{ic|/etc/makepkg.conf}} ou, alternativamente, sobrescrevendo-o com a criação de um ~/.makepkg.conf
 
 
 
</li>
 
<li>
 
Todas as mensagenjs importantes deveriam ser exibidas durante a isntalação usando um arquivo '''.install'''. Por exemplo, se um pacote precisa de configurações extras para funcionar, as direções devem ser incluídas neste arquivo. </li>
 
            <li>Qualquer '''dependência opcional''' que não é necessária para executar o pacote ou que faça-o funcionar, não deveria ser incluída; Ao invés disso, a informação deveria ser adicionada ao vetor <b>optdepends</b>:
 
{{bc|1=
 
 
optdepends=('cups: printing support'
 
optdepends=('cups: printing support'
 
             'sane: scanners support'
 
             'sane: scanners support'
Line 91: Line 80:
 
             'libjpeg: JPEG images support'
 
             'libjpeg: JPEG images support'
 
             'libpng: PNG images support')
 
             'libpng: PNG images support')
}}
+
</nowiki>}}
 +
:O exemplo acima foi tirado do pacote '''wine''' do {{Ic|extra}}. A informação do optdepends é automaticamente exibida na instalação/atualização, de forma que tal informação '''não''' deve-se manter esse tipo de informação em arquivos {{ic|.install}}.
 +
* Ao criar a '''descrição de pacote''' para um pacote, não inclua o nome do pacote, em uma forma autorreferenciativa. Por exemplo, "Nedit is a text editor for X11" poderia ser simplificado em "A text editor for X11". Também tente manter as descrições abaixo de 80 caracteres.
 +
* Tente manter o '''tamanho da linha''' do PKGBUILD abaixo de 100 caracteres.
 +
* Onde for possível, '''remova linhas vazias''' do {{ic|PKGBUILD}} ({{ic|provides}}, {{ic|replaces}}, etc.)
 +
* É uma prática comum '''preservar a ordem''' dos campos do {{ic|PKGBUILD}} informada acima. Porém, isso não é obrigatório, sendo o único requisito neste contexto a '''correção da sintaxe bash'''.
 +
* '''Envolva com aspas''' as variáveis que podem conter espaços, tal como {{ic|"$pkgdir"}} e {{ic|"$srcdir"}}.
 +
* Para garantir a '''integridade''' de pacotes, certifique-se que as [[PKGBUILD (Português)#Integridade|variáveis de integridade]] contêm os valores corretos. Essas podem ser atualizadas usando a ferramenta {{ic|updpkgsums}}.
  
O exemplo acima foi tirado do pacote <b>wine</b> do {{Ic|extra}}. A informação do optdepends é automaticamente exibida na instalação/atualização, de forma que tal informação <b>não</b> deve ser acrescentada em arquivos .install.
+
== Nomenclatura de pacotes ==
  
</li>
+
* Nomes de pacotes devem consistir em '''caracteres alfanuméricos, somente'''; todas as letras devem ser '''minúsculas'''.
        <li>Ao criar a '''description''' para um pacote, não inclua o nome do pacote, em uma forma auto-referenciativa. Por exemplo, "Nedit is a text editor for X11" poderia ser simplificado em "A text editor for X11". Também tente manter as descrições abaixo de 80 caracteres.</li>
+
* Nomes de pacotes NÃO devem ser sufixados com o número de versão principal de lançamento do upstream (ex.: não queremos libfoo2 se upstream chama-o de libfoo v2.3.4) no caso da biblioteca e suas dependências esperadas para serem capazes de manter o uso da maioria das versões recentes de biblioteca com cada lançamento do upstream. Porém, para alguns softwares ou dependências, isso não pode ser presumido. No passado, isso foi especialmente verdadeiro para kits de ferramentas de widget, tal como GTK ou Qt. Softwares que depende em tais kits de ferramentas geralmente podem não ser trivialmente portadas para uma nova versão maior. Como tal, em casos em que softwares podem, trivialmente, se manter funcionando junto com suas dependências, nomes de pacotes devem carregar o sufixo da versão maior (ex.: gtk2, gtk3, qt4, qt5). Para casos em que a maioria das dependências podem se manter funcionando junto com lançamentos mais novos, mas alguns não podem (por exemplo, código fechado que precisa de libpng12 ou similar), uma versão obsoleta daquele pacote pode ser chamado de libfoo1 enquanto a versão atual é apenas libfoo.
<li>Tente manter o '''tamanho da linha''' do PKGBUILD abaixo de 100 caracteres.</li>
 
<li>Onde for possível, '''remova linhas vazias''' do {{ic|PKGBUILD}} ({{ic|provides}}, {{ic|replaces}}, etc.)</li>
 
<li>É uma prática comum '''preservar a ordem''' dos campos do {{ic|PKGBUILD}} informada acima. Apesar disso, isso não é obrigatório, sendo o único requisito neste contexto a '''corretude da sintaxe bash'''.</li>
 
</ul>
 
  
== Nomenclatura de pacotes ==
+
* Versões de pacotes '''devem ser as mesmas que a versão lançada pelo autor'''. Versões podem incluir letras, se for necessário (ex: a versão do nmap é 2.54BETA32). '''Tags de versão não podem incluir hífens!''' Letras, números e pontos, somente.
+
* Lançamentos de pacotes são '''específicos de pacotes do Arch Linux'''. Eles permitem a usuários diferenciar entre compilações de pacotes mais novas das mais antigas. Quando uma nova versão de software do pacote é lançada, o '''contador de lançamento recomeça em 1'''. Então, na medida em que correções e otimizações forem feitas, o pacote será '''relançado''' para o público do Arch Linux e o '''número de lançamento será incrementado'''. Quando uma nova versão for lançada, o contador de lançamento será reiniciado para 1. As tags de lançamento do pacote seguem as '''mesmas restrições de nomenclatura que tags de versão'''.
<ul>
 
<li>
 
Nomes de pacotes devem conter '''caracteres alfanuméricos, somente'''; todas as letras devem ser '''minúsculas'''.
 
</li>
 
<li>
 
Versões de pacotes '''devem ser a mesma que a versão lança para autor'''. Versões podem incluir letras, se for necessário (ex: a versão do nmap é 2.54BETA32). '''A versão não pode incluir hífens!''' Letras, números e pontos, somente.
 
</li>
 
 
 
<li>
 
Lançamento ("releases") de pacotes são '''específicos de pacotes do Arch Linux'''. Eles permitem a usuários diferenciar entre compilações de pacotes mais novas das mais antigas. Quando uma nova versão de software do pacote foi lançada, o '''contador de lançamento recomeça em 1'''. Então, na medida em que correções e otimizações forem feitas, o pacote será '''re-relançado''' para o público do Arch Linux e o '''número de lançamento será incrementado'''. Quando uma nova versão for lançada, o contador de lançamento será reiniciado para 1. O número do lançamento do pacote segue a '''mesma restrição de nomenclatura da versão do pacote'''.
 
</li>
 
</ul>
 
  
 
== Diretórios ==
 
== Diretórios ==
<ul>
 
<li>
 
'''Arquivos de configuração''' devem ser mantidos dentro do diretório {{ic|/etc}}. Se há mais de um arquivo de configuração, é costumeiro '''usar um subdiretório''' para manter a área do {{ic|/etc}} o mais limpo possível. Use {{ic|/etc/{pkgname}/}}, sendo {{ic|<nowiki>{pkgname}</nowiki>}} o nome do pacote (ou uma alternativa adequada, p.ex., o apache usa {{ic|/etc/httpd/}}).
 
</li>
 
  
<li>
+
* '''Arquivos de configuração''' devem ser mantidos dentro do diretório {{ic|/etc}}. Se há mais de um arquivo de configuração, é costumeiro '''usar um subdiretório''' para manter a área do {{ic|/etc}} o mais limpo possível. Use {{ic|/etc/{pkgname}/}}, sendo {{ic|<nowiki>{pkgname}</nowiki>}} o nome do pacote (ou uma alternativa adequada, p.ex., o apache usa {{ic|/etc/httpd/}}).
Os arquivos de pacotes devem seguir essas '''diretrizes gerais de diretórios''':
 
</li>
 
 
<table cellspacing="1" >
 
<tr>
 
<td>{{ic|/etc}}</td>
 
<td style="padding-left: 1em;">
 
Arquivos de configuração '''essenciais para o sistema'''
 
</td>
 
</tr>
 
<tr>
 
<td>{{ic|/usr/bin}}</td>
 
<td style="padding-left: 1em;">Binários de aplicativos</td>
 
</tr>
 
<tr>
 
<td>{{ic|/usr/sbin}}</td>
 
  
<td style="padding-left: 1em;">Binários do sistema</td>
+
* Arquivos de pacotes devem seguir essas '''diretrizes gerais de diretórios''':
</tr>
+
:{|
<tr>
+
|-
<td>{{ic|/usr/lib}}</td>
+
| {{ic|/etc}}
<td style="padding-left: 1em;">Bibliotecas</td>
+
| Arquivos de configuração '''essenciais para o sistema'''
</tr>
+
|-
<tr>
+
| {{ic|/usr/bin}}
<td>{{ic|/usr/include}}</td>
+
| Binários
<td style="padding-left: 1em;">Arquivos headers</td>
+
|-
</tr>
+
| {{ic|/usr/lib}}
<tr>
+
| Bibliotecas
<td>{{ic|<nowiki>/usr/lib/{pkg}</nowiki>}}</td>
+
|-
<td style="padding-left: 1em;">Módulos, plug-ins etc.</td>
+
| {{ic|/usr/include}}
</tr>
+
| Arquivos cabeçalhos (''headers'')
<tr>
+
|-
<td>{{ic|<nowiki>/usr/share/doc/{pkg}</nowiki>}}</td>
+
| {{ic|<nowiki>/usr/lib/{pkg}</nowiki>}}
<td style="padding-left: 1em;">Documentação de aplicativos</td>
+
| Módulos, plug-ins, etc.
</tr>
+
|-
<tr>
+
| {{ic|<nowiki>/usr/share/doc/{pkg}</nowiki>}}
<td>{{ic|/usr/share/info}}</td>
+
| Documentação de aplicativo
<td style="padding-left: 1em;">Arquivos de sistema do GNU Info</td>
+
|-
</tr>
+
| {{ic|/usr/share/info}}
<tr>
+
| Arquivos de sistema do GNU Info
<td>{{ic|/usr/share/man}}</td>
+
|-
<td style="padding-left: 1em;">Páginas Man</td>
+
| {{ic|/usr/share/man}}
</tr>
+
| Páginas de manual (''man'')
<tr>
+
|-
<td>{{ic|<nowiki>/usr/share/{pkg}</nowiki>}}</td>
+
| {{ic|<nowiki>/usr/share/{pkg}</nowiki>}}
<td style="padding-left: 1em;">Dados de aplicativos</td>
+
| Dados de aplicativo
</tr>
+
|-
<tr>
+
| {{ic|<nowiki>/var/lib/{pkg}</nowiki>}}
<td>{{ic|<nowiki>/var/lib/{pkg}</nowiki>}}</td>
+
| Armazenamento persistente de aplicativo
<td style="padding-left: 1em;">Armazenamento persistente de aplicativos</td>
+
|-
</tr>
+
| {{ic|<nowiki>/etc/{pkg}</nowiki>}}
<tr>
+
| Arquivos de configuração de {{ic|<nowiki>{pkg}</nowiki>}}
<td>{{ic|<nowiki>/etc/{pkg}</nowiki>}}</td>
+
|-
<td style="padding-left: 1em;">Arquivos de configuração do {{ic|<nowiki>{pkg}</nowiki>}}</td>
+
| {{ic|<nowiki>/opt/{pkg}</nowiki>}}
</tr>
+
| Pacotes grandes contendo todos os seus arquivos
<tr>
+
|}
<td>{{ic|<nowiki>/opt/{pkg}</nowiki>}}</td>
 
<td style="padding-left: 1em;">
 
Pacotes grandes contendo todos os seus arquivos, como o Java, etc.
 
</td>
 
</tr>
 
</table>
 
  
<li>
+
* Pacotes não devem conter os diretórios abaixo:
Pacotes não devem conter os diretórios abaixo:
+
** {{ic|/bin}}
<ul>
+
** {{ic|/sbin}}
<li>/dev
+
** {{ic|/dev}}
<li>/home
+
** {{ic|/home}}
<li>/srv
+
** {{ic|/srv}}
<li>/media
+
** {{ic|/media}}
<li>/mnt
+
** {{ic|/mnt}}
<li>/proc
+
** {{ic|/proc}}
<li>/root
+
** {{ic|/root}}
<li>/selinux
+
** {{ic|/selinux}}
<li>/sys
+
** {{ic|/sys}}
<li>/tmp
+
** {{ic|/tmp}}
<li>/var/tmp
+
** {{ic|/var/tmp}}
</ul>
+
** {{ic|/run}}
</li>
 
  
</ul>
+
== Tarefas do Makepkg ==
  
==Tarefas do Makepkg==
+
Quando [[makepkg (Português)|makepkg]] é usado para compilar um pacote, ele automaticamente faz o seguinte:
  
<p>
+
# Verifica se as dependências ('''depends''') e dependências em tempo de compilação ('''makedepends''') do pacote estão instaladas
Quando [[makepkg]] é usado para criar um pacote, ele automaticamente faz o seguinte:
+
# '''Baixa os arquivos fontes''' dos servidores
</p>
+
# '''Verifica a integridade ''' de arquivos fonte
 +
# '''Descompacta''' os arquivos fonte
 +
# Realiza qualquer '''patching''' necessário
 +
# '''Compila''' o software e instala-o em um ''fakeroot''
 +
# Remove ('''strips''') símbolos de binários
 +
# Remove ('''strips''') símbolos de depuração de bibliotecas
 +
# '''Compacta''' páginas de manual e/ou info
 +
# Gera o '''meta-arquivo de pacote''', o qual é incluído em cada pacote
 +
# '''Compacta''' o ''fakeroot'' no arquivo de pacote
 +
# '''Armazena''' o arquivo de pacote no diretório de destino configurado (por padrão, <span title="Diretório de trabalho atual" style="border-bottom: 1px dotted">cwd</span>)
  
<ol>
+
==Arquiteturas==
<li>
 
Verifica se as dependências ('''dependencies''') e dependências em tempo de compilação ('''makedepends''') do pacote estão instaladas
 
</li>
 
<li>
 
'''Baixar os arquivos fontes''' dos servidores
 
</li>
 
<li>
 
'''Verifica a integridade ''' de arquivos fonte
 
</li>
 
<li>
 
'''Descompacta''' os arquivos fonte
 
</li>
 
<li>
 
Realiza qualquer '''patch''' necessário
 
</li>
 
<li>
 
  
'''Compila''' o software e instala-o em um fakeroot (ambiente falso)
+
O vetor {{Ic|arch}} deve conter {{Ic|'i686'}} e/ou {{Ic|'x86_64'}}, dependendo de em quais arquiteturas o pacote pode ser compilado. Você também pode usar {{Ic|'any'}} para pacotes que independem de arquitetura.
</li>
 
<li>
 
Remove ('''strips''') símbolos de binários
 
</li>
 
<li>
 
Remove ('''strips''') símbolos de depuração de biblotecas
 
</li>
 
<li>
 
'''Compacta''' páginas de manual e/ou info
 
</li>
 
<li>
 
Gera o '''meta-arquivo de pacote''', o qual é incluído em cada pacote
 
</li>
 
 
 
<li>
 
'''Compresses''' the fake root into the package file
 
</li>
 
<li>
 
'''Armazena''' o arquivo de pacote no diretório configurado (por padrão, no <span title="Current Working Directory" style="border-bottom:1px dotted">cwd</span>)
 
</li>
 
 
 
</ol>
 
 
 
==Arquiteturas==
 
O vetor {{Ic|arch}} deve conter {{Ic|'i686'}} e/ou {{Ic|'x86_64'}}, dependendo de quais arquiteturas o pacote pode ser compilado. Você também pode usar {{Ic|'any'}} para pacotes que independem de arquitetura.
 
  
 
==Licenças==
 
==Licenças==
A variável de vetor [[Licenses|license]] está sendo implementada nos repositórios oficiais, e ela <b>deve</b> ser usada em seus pacotes da mesma forma. Use-a da seguinte forma:
 
<ul>
 
<li>Um pacote de licenças foi criado no [core] armazenando as licenças comuns em /usr/share/licenses/common (ex: /usr/share/licenses/common/GPL).  Se um pacote está licenciado sbo uma dessas licenças, a variável de licenças deve ser definido com o nome do diretório, p. ex: license=('GPL')</li>
 
<li>Se a licença apropriada não estiver incluída no pacote oficial de licenças, várias coisas devem ser feitas:
 
<ol>
 
<li>Os arquivos de licença devem ser incluídos em /usr/share/licenses/$pkgname/. Por exemplo: /usr/share/licenses/dibfoo/LICENSE. Uma ótima forma de fazer isso é usando:
 
{{bc|install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"}}
 
</li>
 
<li>Se o tarball fonte NÃO contém os detalhes da licenças e a licença é exibida somente no site, por exemplo, então copie a licença para um arquivo e inclua-o no pacote. Lembre-se de chamar este arquivo de forma apropriada também.
 
<li>Adicione 'custom' no vetor de licenças.  Opcionalmente, você pode substituir 'custom' com 'custom:"nome da licença"'.</li>
 
</ol></li>
 
<li>Quando uma licença é usada em um ou mais pacotes no repositório oficial, incluindo [community], ela vira uma licença comum</li>
 
<li>As licenças MIT, BSD, zlib/libpng e Python são casos especiais e não podem ser incluidos no pacote de licenças "comuns". Do ponto de vista da variável de licenças, deve ser tratado com uma licença comum (license=('BSD'), license=('MIT'), license=('ZLIB') ou license=('Python')), mas do ponto de vista do sistema de arquivos, é uma variável personalizada, porque cada licença terá sua própria linha de copyright. Cada pacote licenciado com MIT, BSD, zlib/libpng ou Python devem ter seus locais únicos de armazenamento em /usr/share/licenses/$pkgname/.</li>
 
<li>Alguns pacotes podem não estar cobertos por uma única licença. Nesses casos, várias entradas pode ser feitas no vetor license, p. ex.: license=("GPL" "custom:alguma-licença-comercial"). Para a maioria dos pacotes, essas licenças funcionam de em situações diferentes, ao contrário de se aplicarem ao mesmo tempo. Quando pacman tiver a habilidade de filtrar licenças (para que você possa dizer, "Eu quero somente softwares licenciados com GPL e BSD") duas (ou mais) licenças serão tratadas pelo pacman usando o operador lógico OU, ao invés de E, de forma que o pacman vai considerar o exemplo anterior como um software licenciado via GPL, independentemente das outras licenças listadas.</li>
 
<li>A (L)GPL tem várias versões e permutações dessas versões. Para softwares (L)GPL, a conveção é:
 
<ul>
 
<li>(L)GPL - (L)GPLv2 ou qualquer versão posterior</li>
 
<li>(L)GPL2 - (L)GPL2 somente</li>
 
<li>(L)GPL3 - (L)GPL3 ou qualquer versão posterior</li>
 
</ul>
 
</li>
 
</ul>
 
  
==Enviando pacotes para o AUR==
+
Veja [[PKGBUILD (Português)#license|PKGBUILD#license]].
<p>Note o seguinte antes de enviar qualquer pacote para o AUR:</p>
 
 
 
<ol>
 
        <li>
 
                Os PKGBUILDs enviados '''NÃO DEVEM''' compilar aplicativos já disponíveis em qualquer dos repositórios oficiais de binários em circunstância nenhuma. Excepção a esta estrita regra pode ser somente para pacotes que tenham recursos extras e/ou pacthes em comparação com as versões oficiais. Nesta ocasição, a variável de vetor pkgname deve ser diferente para expressar esta diferença.
 
Por exemplo, Um PKGBUILD do GNU screen enviado contendo patch para a barra lateral (sidebar), poderia ser chamado de screen-sidebar etc. Além disso, a variável de vetor '''provides=('screen')''' deve estar definida no PKGBUILD de forma a evitar conflito com o pacote oficial.
 
        </li>
 
<li>
 
Para conferir segurança aos pacotes enviados para o AUR please '''certifique-se''' de que você preencheu corretamente o campo de {{ic|md5sum}}.  Os {{ic|md5sum}}s podem ser gerados usando o comando {{ic|makepkg -g}}.
 
</li>
 
<li>
 
Por favor '''adicione uma linha de comentário''' ao topo do arquivo {{ic|PKGBUILD}} que siga este formato.
 
                Lembre-se de disfarçar seu e-mail para se proteger de spams:
 
 
 
{{bc|# Maintainer: Seu Nome <endereço at domínio ponto com>}}
 
 
 
Se você está assumindo o papel de mantenedor de um PKGBUILD existente, adicione sdeu nome no topo como descrito abaixo e altere o título do mantenedor (Maintainer) para contribuidor (Contributor):
 
 
 
{{bc|# Maintainer: Seu Nome <endereço at domínio ponto com>
 
# Contributor: Nome Anterior <endereço at domínio ponto com>}}
 
 
 
</li>
 
<li>
 
Verifique as '''dependências''' do pacote (p.ex.: execute
 
{{ic|ldd}} nos executáveis dinâmicos, verifique as ferramentas necessárias por scripts, etc).
 
 
 
A equipe de TUs recomenda '''fortemente''' o uso do utilitário
 
{{ic|namcap}}, escrito por Jason Chu (jason@archlinux.org), para analisar a
 
sanidade dos pacotes. O {{ic|namcap}} vai avisar você sobre
 
permissões incorretas, dependências faltando, dependências desnecessárias,
 
e outros erros comuns. Você pode instalar o pacote {{ic|namcap}} com o {{ic|pacman}}.
 
 
 
Lembre-se de que o {{ic|namcap}} pode ser usado para verificar tanto os arquivos pkg.tar.gz quanto os PKGBUILDs
 
</li>
 
<li> As '''dependências''' são a maioria dos erros de empacotamento. Namcap pode ajudar a detectar tais erros, mas nem sempre está correto. Verifique as dependências consultando na documentação do código fonte e no site do programa. </li>
 
<li>'''Não use o {{Ic|replaces}}''' em um PKGBUILD a não ser que o pacote tenha sido renomeado, como, por exemplo, quando ''Ethereal'' se tornou ''Wireshark''. Se o pacote é uma versão alternativa de um pacote já existente, use {{Ic|conflicts}} (e {{Ic|provides}}, se aquele pacote é necessário por outros). A diferença principal é: depois de sincronizar (-Sy), o pacman vai imediatamente querer substituir um pacote instalado, sobrescrevendo-o pelo pacote encontrado com o correspondente {{Ic|replaces}} onde quer que esteja nos repositórios; O {{Ic|conflicts}}, por outro lado, será somente avaliado quando se estiver instalado o pacote, que é o comportamento desejado porque é menos invasivo.</li>
 
<li>
 
Todos os arquivos enviados para o AUR devem conter um '''arquivo tar compactado ''' contendo um diretório com o '''{{ic|PKGBUILD}}''' e '''arquivos de compilação adicionais''' (patches, install etc.).
 
{{bc|foo/PKGBUILD
 
foo/foo.install
 
foo/foo_bar.diff
 
foo/foo.rc.conf}}
 
O nome do arquivo deve conter o nome do pacote, como, por exemplo, foo.tar.gz.
 
 
 
Pode-se facilmente criar um tarball contendo todos os arquivos necessários usando {{Ic|makepkg --source}}. Isso vai criar um tarball chamado {{Ic|$pkgname-$pkgver-$pkgrel.src.tar.gz}}, o qual pode então ser enviado para o AUR.
 
 
O tarball '''não pode''' conter o tarball de binário criado pelo makepkg, nem deveria conter a lista de arquivos
 
</li>
 
 
 
</ol>
 
  
 
== Diretrizes adicionais ==
 
== Diretrizes adicionais ==
 
Ceritique-se de ler primeiro as diretrizes acima - pontos importantes são listados nesta página e que não serão repetidos nas páginas de diretrizes a seguir. As diretrizes específicas abaixo têm a intenção de ser um adicionar aos padrões listados nesta.
 
Ceritique-se de ler primeiro as diretrizes acima - pontos importantes são listados nesta página e que não serão repetidos nas páginas de diretrizes a seguir. As diretrizes específicas abaixo têm a intenção de ser um adicionar aos padrões listados nesta.
  
=== Pacotes de CVS (SVN, GIT, HG etc.) ===
+
{{Package guidelines}}
Por favor, ver as [[Arch CVS & SVN PKGBUILD guidelines|diretrizes de PKGBUILD de CVS do Arch]]
 
 
 
=== Pacotes de plug-ins do Eclipse ===
 
Por favor, ver as [[Eclipse plugin package guidelines|diretrizes de pacotes de plug-ins do Eclipse]]
 
 
 
=== Pacotes de GNOME ===
 
Por favor, ver as [[GNOME Package Guidelines|diretrizes de pacotes do GNOME]]
 
 
 
=== Pacotes de Go ===
 
Por favor, ver as [[Go Package Guidelines|diretrizes de pacotes de Go]]
 
 
 
=== Pacotes de Haskell ===
 
Por favor, ver as [[Haskell package guidelines|diretrizes de pacotes de Haskell]]
 
 
 
=== Pacotes de Java ===
 
Por favor, ver as [[Java Package Guidelines|diretrizes de pacotes de Java]]
 
 
 
=== Pacotes do KDE ===
 
Por favor, ver as [[KDE Package Guidelines|diretrizes de pacotes do KDE]]
 
 
 
=== Pacotes de módulos de kernel ===
 
Por favor, ver as [[Kernel Module Package Guidelines|diretrizes de pacotes de módulos do kernel]]
 
 
 
=== Pacotes de Lisp ===
 
Por favor, ver as [[Lisp Package Guidelines|diretrizes de pacotes de Lisp]]
 
 
 
=== Pacotes de OCaml ===
 
Por favor, ver as [[OCaml_Package_Guidelines|diretrizes de pacotes de Ocaml]]
 
 
 
=== Pacotes de Perl ===
 
Por favor, ver as [[Perl Package Guidelines|diretrizes de pacotes de Perl]]
 
 
 
=== Pacotes de Python ===
 
Por favor, ver as [[Python Package Guidelines|diretrizes de pacotes de Python]]
 
 
 
=== Pacotes de Ruby Gem ===
 
Por favor, ver as [[Ruby Gem Package Guidelines|diretrizes de pacotes de Ruby Gem]]
 
 
 
=== Pacotes de Wine ===
 
Por favor, ver as [[Arch wine PKGBUILD guidelines|diretrizes de pacotes de Wine]]
 
  
=== Pacotes de MinGW===
+
Pacotes enviados ao AUR também devem estar em conformidade com as [[Arch User Repository (Português)#Regras de envio|regras de envio]].
Por favor, ver as [[MinGW PKGBUILD guidelines|diretrizes de pacotes de MingW]]
 

Latest revision as of 12:17, 30 June 2017

Ao compilar pacotes para o Arch Linux, siga as diretrizes de empacotamento abaixo, especialmente se a intenção é contribuir com um novo pacote para o Arch Linux. Você também deve ler as páginas de manual do PKGBUILD e do makepkg.

Protótipo de PKGBUILD

# Maintainer: Seu nome <seu-email@domínio.com>
pkgname=NOME
pkgver=VERSÃO
pkgrel=1
pkgdesc=""
arch=()
url=""
license=('GPL')
groups=()
depends=()
makedepends=()
optdepends=()
provides=()
conflicts=()
replaces=()
backup=()
options=()
install=
changelog=
source=($pkgname-$pkgver.tar.gz)
noextract=()
md5sums=() #gerado com updpkgsums

build() {
  cd "$pkgname-$pkgver"

  ./configure --prefix=/usr
  make
}

package() {
  cd "$pkgname-$pkgver"

  make DESTDIR="$pkgdir/" install
}

Outros protótipos podem ser encontrados em /usr/share/pacman dos pacotes pacman e abs.

Etiqueta de pacotes

  • Os pacotes jamais devem ser instalados em /usr/local
  • Não introduza novas variáveis no scripts de compilação PKGBUILD, a menos que o pacote não possa ser compilado sem elas, pois elas podem conflitar com variáveis usadas pelo próprio makepkg.
  • Se uma nova variável for absolutamente necessária, prefixe um caractere de sublinhado (_), ex:
    _variavelpersonalizada=
  • O campo packager do meta-arquivo do pacote pode ser personalizado pelo compilador do pacote, modificando a opção apropriada no arquivo /etc/makepkg.conf ou, alternativamente, sobrescrevendo-o com a criação de um ~/.makepkg.conf
  • Todas as mensagens importantes devem ser exibidas durante a instalação usando um arquivo .install. Por exemplo, se um pacote precisa de configurações extras para funcionar, as direções devem ser incluídas neste arquivo.
  • Dependências são os erros mais comuns de empacotamento. Por favor, invista um tempo em verificá-las cuidadosamente, por exemplo executando ldd em executáveis dinâmicos, verificando ferramentas necessárias por scripts ou olhando documentação do software. O utilitário namcap pode lhe ajudar neste assunto. Essa ferramenta pode analisar ambos PKGBUILD e o tarball de pacote resultante e vai avisar você sobre permissões erradas, dependências em falta, dependências redundantes e outros erros comuns.
  • Quaisquer dependências opcionais que não são necessárias para executar o pacote ou que faça-o funcionar, não devem ser incluídas no vetor depends; em vez disso, a informação deve ser adicionada ao vetor optdepends:
optdepends=('cups: printing support'
            'sane: scanners support'
            'libgphoto2: digital cameras support'
            'alsa-lib: sound support'
            'giflib: GIF images support'
            'libjpeg: JPEG images support'
            'libpng: PNG images support')
O exemplo acima foi tirado do pacote wine do extra. A informação do optdepends é automaticamente exibida na instalação/atualização, de forma que tal informação não deve-se manter esse tipo de informação em arquivos .install.
  • Ao criar a descrição de pacote para um pacote, não inclua o nome do pacote, em uma forma autorreferenciativa. Por exemplo, "Nedit is a text editor for X11" poderia ser simplificado em "A text editor for X11". Também tente manter as descrições abaixo de 80 caracteres.
  • Tente manter o tamanho da linha do PKGBUILD abaixo de 100 caracteres.
  • Onde for possível, remova linhas vazias do PKGBUILD (provides, replaces, etc.)
  • É uma prática comum preservar a ordem dos campos do PKGBUILD informada acima. Porém, isso não é obrigatório, sendo o único requisito neste contexto a correção da sintaxe bash.
  • Envolva com aspas as variáveis que podem conter espaços, tal como "$pkgdir" e "$srcdir".
  • Para garantir a integridade de pacotes, certifique-se que as variáveis de integridade contêm os valores corretos. Essas podem ser atualizadas usando a ferramenta updpkgsums.

Nomenclatura de pacotes

  • Nomes de pacotes devem consistir em caracteres alfanuméricos, somente; todas as letras devem ser minúsculas.
  • Nomes de pacotes NÃO devem ser sufixados com o número de versão principal de lançamento do upstream (ex.: não queremos libfoo2 se upstream chama-o de libfoo v2.3.4) no caso da biblioteca e suas dependências esperadas para serem capazes de manter o uso da maioria das versões recentes de biblioteca com cada lançamento do upstream. Porém, para alguns softwares ou dependências, isso não pode ser presumido. No passado, isso foi especialmente verdadeiro para kits de ferramentas de widget, tal como GTK ou Qt. Softwares que depende em tais kits de ferramentas geralmente podem não ser trivialmente portadas para uma nova versão maior. Como tal, em casos em que softwares podem, trivialmente, se manter funcionando junto com suas dependências, nomes de pacotes devem carregar o sufixo da versão maior (ex.: gtk2, gtk3, qt4, qt5). Para casos em que a maioria das dependências podem se manter funcionando junto com lançamentos mais novos, mas alguns não podem (por exemplo, código fechado que precisa de libpng12 ou similar), uma versão obsoleta daquele pacote pode ser chamado de libfoo1 enquanto a versão atual é apenas libfoo.
  • Versões de pacotes devem ser as mesmas que a versão lançada pelo autor. Versões podem incluir letras, se for necessário (ex: a versão do nmap é 2.54BETA32). Tags de versão não podem incluir hífens! Letras, números e pontos, somente.
  • Lançamentos de pacotes são específicos de pacotes do Arch Linux. Eles permitem a usuários diferenciar entre compilações de pacotes mais novas das mais antigas. Quando uma nova versão de software do pacote é lançada, o contador de lançamento recomeça em 1. Então, na medida em que correções e otimizações forem feitas, o pacote será relançado para o público do Arch Linux e o número de lançamento será incrementado. Quando uma nova versão for lançada, o contador de lançamento será reiniciado para 1. As tags de lançamento do pacote seguem as mesmas restrições de nomenclatura que tags de versão.

Diretórios

  • Arquivos de configuração devem ser mantidos dentro do diretório /etc. Se há mais de um arquivo de configuração, é costumeiro usar um subdiretório para manter a área do /etc o mais limpo possível. Use /etc/{pkgname}/, sendo {pkgname} o nome do pacote (ou uma alternativa adequada, p.ex., o apache usa /etc/httpd/).
  • Arquivos de pacotes devem seguir essas diretrizes gerais de diretórios:
/etc Arquivos de configuração essenciais para o sistema
/usr/bin Binários
/usr/lib Bibliotecas
/usr/include Arquivos cabeçalhos (headers)
/usr/lib/{pkg} Módulos, plug-ins, etc.
/usr/share/doc/{pkg} Documentação de aplicativo
/usr/share/info Arquivos de sistema do GNU Info
/usr/share/man Páginas de manual (man)
/usr/share/{pkg} Dados de aplicativo
/var/lib/{pkg} Armazenamento persistente de aplicativo
/etc/{pkg} Arquivos de configuração de {pkg}
/opt/{pkg} Pacotes grandes contendo todos os seus arquivos
  • Pacotes não devem conter os diretórios abaixo:
    • /bin
    • /sbin
    • /dev
    • /home
    • /srv
    • /media
    • /mnt
    • /proc
    • /root
    • /selinux
    • /sys
    • /tmp
    • /var/tmp
    • /run

Tarefas do Makepkg

Quando makepkg é usado para compilar um pacote, ele automaticamente faz o seguinte:

  1. Verifica se as dependências (depends) e dependências em tempo de compilação (makedepends) do pacote estão instaladas
  2. Baixa os arquivos fontes dos servidores
  3. Verifica a integridade de arquivos fonte
  4. Descompacta os arquivos fonte
  5. Realiza qualquer patching necessário
  6. Compila o software e instala-o em um fakeroot
  7. Remove (strips) símbolos de binários
  8. Remove (strips) símbolos de depuração de bibliotecas
  9. Compacta páginas de manual e/ou info
  10. Gera o meta-arquivo de pacote, o qual é incluído em cada pacote
  11. Compacta o fakeroot no arquivo de pacote
  12. Armazena o arquivo de pacote no diretório de destino configurado (por padrão, cwd)

Arquiteturas

O vetor arch deve conter 'i686' e/ou 'x86_64', dependendo de em quais arquiteturas o pacote pode ser compilado. Você também pode usar 'any' para pacotes que independem de arquitetura.

Licenças

Veja PKGBUILD#license.

Diretrizes adicionais

Ceritique-se de ler primeiro as diretrizes acima - pontos importantes são listados nesta página e que não serão repetidos nas páginas de diretrizes a seguir. As diretrizes específicas abaixo têm a intenção de ser um adicionar aos padrões listados nesta.

Package creation guidelines

CLRCrossEclipseFree PascalGNOMEGoHaskellJavaKDEKernelLispMinGWNode.jsNonfreeOCamlPerlPHPPythonRubyVCSWebWine

Pacotes enviados ao AUR também devem estar em conformidade com as regras de envio.