Padrao Arch de empacotamento

De Wiki do Arch Linux Brasil

Tabela de conteúdo 1 Padrão de Empacotamento 1.1 Protótipo do PKGBUILD 1.2 Regras de Etiqueta para Pacotes 1.3 Nomeação de Pacotes 1.4 Diretórios 1.5 Deveres do Makepkg 1.6 Arquiteturas 1.7 Licenças 1.8 Submetendo Pacotes para o AUR 2 Orientações adicionais 2.1 Pacotes CVS/SVN Packages 2.2 Pacotes Eclipse Plugin 2.3 Pacotes Gnome 2.4 Pacotes Haskell 2.5 Pacotes Java 2.6 Pacotes Kernel Module 2.7 Pacotes Lisp 2.8 Pacotes Perl 2.9 Pacotes Python 2.10 Pacotes Ruby Gem 2.11 Pacotes Wine

Padrão de Empacotamento

Os PKGBUILDs submetidos NÃO DEVEM gerar aplicações já existentes em qualquer um dos repositórios oficiais em quaisquer circunstâncias. A única exceção a esta regra se aplica somente quando os pacotes possuírem recursos extras habilitados ou correções em relação aos originais. Nesta ocasião o array pkgname deve ser diferente para expressar essa diferença.

Quando estiver construindo pacotes para o Arch Linux, você deve seguir as orientações sobre pacotes abaixo, principalmente se você gostaria de contribuir com seu novo pacote para o Arch Linux. Você também deve dar uma lida nas manpages do PKGBUILD e do makepkg.

Protótipo do PKGBUILD

# Contributor: Seu Nome <seuemail at domain dot com> (disfarce seu email para proteção contra spam)

pkgname=NOME
pkgver=VERSÂO
pkgrel=1
pkgdesc=""
arch=('i686' 'x86_64')
url="http://ENDEREÇO/"
license=('GPL')
groups=()
depends=()
makedepends=()
optdepends=()
provides=()
conflicts=()
replaces=()
backup=()
options=()
install=
source=($pkgname-$pkgver.tar.gz)
noextract=()
md5sums=() #gerar com 'makepkg -g'

build() {
  cd $srcdir/$pkgname-$pkgver
  ./configure --prefix=/usr
  make || return 1
  make DESTDIR=$pkgdir install || return 1
}

Regras de Etiqueta para Pacotes

• Pacotes nunca devem ser instalados em /usr/local
• Quando possível, use "|| return 1" em funções importantes de construção

patch -Np1 -i ../patchfile.patch || return 1
make || return 1
make DESTDIR=$pkgdir install || return 1

• Não introduza variáveis novas em seu PKGBUILD, ao menos que o pacote não possa ser construído sem elas, pois as mesmas possivelmente podem conflitar com as variáveis utilizadas pelo makepkg.

Se uma variável nova for absolutamente necessária, adicione um underscore como prefixo (_) ex:

_customvariable=

O AUR não consegue detectar o uso de variáveis personalizadas e também não consegue usar-las em substituições. Isto pode ser muitas vezes visto no array source, ex:

http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2

Tal situação derruba a funcionalidade eficaz do AUR.

• Evite usar /usr/libexec/ para qualquer coisa. Ao invés disso use /usr/lib/${pkgname}/.
• O campo packager do PKGBUILD pode ser personalizado pelo empacotador, modificando a opção apropriada no arquivo /etc/makepkg.conf, ou exportando a variável de ambiente PACKAGER antes de construir um pacote com o makepkg:

# export PACKAGER="John Doe@your.email"

• Todas as mensagens importantes devem ser ecoadas durante a instalação usando o arquivo .install. Por exemplo, se um pacote precisa um setup extra para funcionar, as instruções devem ser incluídas.
• Qualquer dependência opcional que não seja vital para o funcionamento do pacote, não devem ser incluídas; ao invés disso a informação deve ser adicionada no array 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 repositório extra. As informações do optdepends serão automaticamente mostrados na tela durante a instalação/upgrade a partir do pacman 3.2.1, logo não se deve mais manter este tipo de informação no arquivo .install.

• Quando estiver criando um package description para um pacote, não inclua o nome do pacote na descrição. Por exemplo, "Nedit is a text editor for X11", pode ser simplificado para "A text editor for X11". Tente também manter as descrições com até 80 caracteres ou menos.
• Tente manter o comprimento das linhas no PKGBUILD com menos de 100 caracteres.
• Quando possível, remova linhas em branco do PKGBUILD (provides, replaces, etc.)
• É uma pratica comum preservar a ordem dos campos no PKGBUILD como mostrado acima. No entanto isto não é mandatório, a única exigência neste contexto é a correta sintaxe do bash.

Nomeação de Pacotes

• Os nomes de pacotes devem consistir em caracteres alfanuméricos somente; todas as letras devem ser minúsculas
• As versões dos pacotes devem ser as mesmas da versão lançada pelo autor. Versões podem incluir letras se necessário (ex. a versão nmaps´s 2.54BETA32). As tags de versões não devem incluir hífens!. Letras, números e pontos somente.
• Os "releases" dos pacotes são específicos dos pacotes do Arch Linux. Isto permite aos usuários diferenciar os pacotes novos dos velhos. Quando uma versão nova de um pacote é lançada, o contador do release inicia em 1. Quando correções e otimizações são feitas, o pacote será re-lançado para todo o público e seu contador do release será incrementado. Quando sai uma nova versão, o contador volta a 1. A tag release dos pacotes segue a mesma restrição de nomeação das tags de versões.

Diretórios

• Arquivos de configuração devem ser colocados no diretório /etc. Se existir mais de um arquivo de configuração, é de costume usar um subdiretório a fim de manter o /etc o mais limpo possível. Use /etc/{pkgname}/ onde {pkgname} é o nome de seu pacote (ou uma alternativa adequada, ex. O apache usa /etc/httpd/).
• Os arquivos de pacotes devem seguir estas orientações gerais para diretórios:

/etc	Arquivos de configuração
/usr/bin	Aplicativos binários
/usr/sbin	Binários do sistema
/usr/lib	Bibliotecas
/usr/include	Cabeçalhos
/usr/lib/{pkg}	Módulos, plugins, etc
/usr/share/doc	Documentação
/usr/share/info	Arquivos de sistema GNU Info
/usr/share/man	Manpages
/usr/share/{pkg}	Dados do aplicativo
/var/lib/{pkg}	Aplicação de armazenamento persistente
/etc/{pkg}	Arquivos de configuração para {pkg}
/opt/{pkg}	Grandes pacotes auto contidos como o Java, etc.

• Os pacotes não devem conter os seguintes diretórios:
  • /dev
  • /home
  • /media
  • /mnt
  • /proc
  • /root
  • /selinux
  • /sys
  • /tmp
  • /var/tmp

Deveres do Makepkg

Quando você usa o makepkg para construir um pacote, ele faz o seguinte automaticamente:

1. Confere se as dependências e as "makedepends" do pacote estão instaladas
2. Faz o download dos fontes do servidor
3. Confere a integridade dos arquivos fontes
4. Desempacota os fontes
5. Aplica qualquer patch necessário
6. Constrói o software e o instala em um fake root
7. Extrai simbolos dos binários
8. Compacta manuais ou páginas info
9. Gera o meta arquivo do pacote que vem incluido em cada pacote
10. Compacta o fake root no arquivo do pacote
11. Armazena o arquivo do pacote no diretório de destino configurado (cwd por padrão)

Arquiteturas

O array arch deve conter 'i686' e/ou 'x86_64' dependendo da arquitetura em que pode ser construindo. Você também pode usar 'any' para pacotes independentes de arquitetura.

Licenças

O array de licensas está sendo implementado aos poucos nos repositórios oficiais, mesmo assim ele deve ser usado em seu pacote. Você pode usá-lo como segue:

• Um pacote de licenças foi criado no [core] que armazena licenças comuns em /usr/share/licenses/common, por exemplo, /usr/share/licenses/commom/GPL.
• Se a licença apropriada não estiver inclusa no pacote de licenças oficiais, várias coisas deverão ser feitas:
  1. O arquivo da licença deve ser incluido em /usr/share/licenses/$pkgname/, por exemplo, /usr/share/licenses/dibfoo/COPYING.
  2. Se o tarball fonte não contém os detalhes da licença e a licença só for exibida em uma página web por exemplo, então você deve copiar a licença para um arquivo e incluí-lo.
  3. Adicione 'custom' ao array licenses. Opcionalmente, você pode substituir o 'custom' por 'custom:"nome da licença"'
• Uma vez que as licenças aparecerem em dois ou mais pacotes num repositório oficial, incluindo o [community], ela se torna comum.
• As licenças MIT, BSD, zlib/ligpng e Python, são casos especiais e não devem devem ser inclusas no pacote de licenças 'common'. Por causa da variável de licença, é tratado como uma licença comum (license=('BSD'), license=('MIT'), license=('ZLIB') or license=('Python')), mas por causa do sistema de arquivos, que é uma licença custom, pois cada um tem sua própria linha de copyright. Cada pacote licenciado sobre estas licenças devem ter sua licença armazenada em /usr/share/licences/$pkgname/.
• Alguns pacotes podem não ser cobertos por uma única licença. Nestes casos multiplas entradas podem ser feitas no array de licenças ex.: license=("GPL" "custom:alguma licença comercial"). Para a maioria dos pacotes estas licenças se aplicam em diferentes casos, e não simultaneamente. Com a capacidade do pacman de filtrar a licenças (de modo que você pode dizer: "Eu só quero software licenciado sob GPL e BSD")licenças dupla (ou mais) serão tratadas pelo pacman usando "OU", em vez de "E", assim o pacman irá considerar o exemplo acima como software licenciado sob GPL, independentemente das outras licenças listadas.
• A (L)GPL tem muitas versões e permutações dessas versões. Para software (L)GPL, a convenção é:
  • (L)GPL - (L)GPLv2 ou qualquer versão posterior
  • (L)GPL2 - (L)GPL2 somente
  • (L)GPL3 - (L)GPL3 ou qualquer versão posterior

Submetendo Pacotes para o AUR

Tome as seguintes precauções antes de submeter um pacote para o AUR:

1. Os PKGBUILDs submetidos NÃO DEVEM construir aplicativos já presentes em algum dos repositórios oficiais sob quaisquer circunstâncias. Exceções a esta rígida regra só se aplicam em pacotes com recursos extras habilitado e/ou correções em relação aos oficiais. Em tal ocasião o array pkgname deve ser diferente para expressar essa diferença. Por exemplo, o PKGBUILD GNU screen submetido contendo a barra lateral, pode ser chamado screen-sidebar etc. Além disso, o array provides=('screen') do PKGBUILD deve ser utilizada a fim de evitar conflitos com o pacote oficial.

1. Para garantir a segurança de pacotes apresentados ao AUR favor ter certeza de que você tenha preenchido corretamente o campo md5sum. Os md5sum podem ser gerados usando o comando makepkg -g.

1. Por favor, adicione uma linha de comentário no topo de seu arquivo PKGBUILD que siga este formato. Lembre-se de disfarçar seu email para se proteger contra spam.

   # Contributor: Seu Nome <address at domain dot com>

1. Verifique as dependências do pacote (ex. execute ldd em executáveis dinâmicos, confira as ferramentas necessárias pelos scripts, etc.). A equipe de TU(Trusted Users) fortemente recomenda utilizar a ferramenta namcap, escrito por Jason Chu (jason@archlinux.org), para análise de sanidade de seu pacote. O namcap dirá a você sobre permissões erradas, dependências faltantes, dependências desnecessárias e outros erros comuns. Lembre-se, o namcap pode ser usado para verificar os arquivos PKGBUILDs e pkg.tar.gz

1. Dependências são os erros mais comuns no empacotamemto. O namcap pode ajudar a encontrá-los, mas nem sempre ele está correto. Verfique as dependências conferindo a documentação dos fontes e o site do programa.

1. Não use replaces em seu PKGBUILD a não ser que você queira renomear seu pacote, por exemplo quando Ethereal se torna Wireshark. Se você acabou de fornecer uma versão alternativa de um pacote já existente, use conlicts (e provides se este pacote é requerido por outros). A diferença principal é: após a sincronização (-Sy), o pacman imediatamente vai querer substituir um instalado, 'ofendendo' o pacote após encontrar um pacote correspondente ao que estiver em replaces em qualquer lugar de seus repositórios; conflicts por outro lado, somente será avaliado quando estiver instalando o pacote, que é praticamente sempre o comportamento desejado porque você não deve empurrar seu pacote goela abaixo nas pessoas.
2. Todos os arquivos enviados para o AUR devem estar contidos num arquivo tar compactado contendo o diretório com o PKGBUILD e os arquivos adicionais (patches, install, ...)

foo/PKGBUILD 
foo/foo.install
foo/foo_bar.diff
foo/foo.rc.conf

O nome do arquivo deve conter o nome do pacote, ex. foo.tar.gz. Você pode facilmente construir um tarball contendo todos os arquivos necessários usando makepkg --source. Isto gera um tarball na forma $pkgname-$pkgver-$pkgrel.src.tar.gz, que é o que você pode enviar ao AUR. O tarball não deve conter o tarball binário criado pelo makepkg, nem deve conter a lista de arquivos.

Orientações adicionais

Tenha certeza de ler os guias abaixo primeiro - pontos importantes foram listados nesta página que não irão se repetir nas orientações que seguem. Estas orientações específicas são um complemento aos padrões listados nesta página.

Pacotes CVS/SVN Packages

De uma olhada em Arch CVS & SVN PKGBUILD guidelines

Pacotes Eclipse Plugin

De uma olhada em Eclipse plugin package guidelines

Pacotes Gnome

De uma olhada em Gnome package guidelines

Pacotes Haskell

De uma olhada em Haskell package guidelines

Pacotes Java

De uma olhada em Java Package Guidelines

Pacotes Kernel Module

De uma olhada em Kernel Module Package Guidelines

Pacotes Lisp

De uma olhada em Lisp Package Guidelines

Pacotes Perl

De uma olhada em Perl Package Guidelines

Pacotes Python

De uma olhada em Python Package Guidelines

Pacotes Ruby Gem

De uma olhada em Ruby Gem Package Guidelines

Pacotes Wine

De uma olhada em Arch wine PKGBUILD guidelines