# Arch packaging standards (Português)

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.

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 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 'makepkg -g'

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

      ./configure --prefix=/usr
      make
    }

    package() {
      cd "$srcdir/$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 nunca devem ser instalados em `/usr/local`
- Não introduza novas variáveis em 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, acrescente, antes da variável, um underscore (`_`), ex:

      _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:

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

  Tal situação acaba com a funcionalidade efetiva do AUR.

- Evite usar `/usr/libexec/` para qualquer coisa. Ao invés disso, use `/usr/lib/${pkgname}/`.
- O campo `packager` do meta arquivo do pacote pode ser personalizado para 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 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.
- 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 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 ser acrescentada em arquivos .install.

- 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.
- 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. Apesar disso, isso não é obrigatório, sendo o único requisito neste contexto a corretude da sintaxe bash.

## Nomenclatura de pacotes

- Nomes de pacotes devem conter caracteres alfanuméricos, somente; todas as letras devem ser minúsculas.
- 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.
- 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.

## 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/`).
- Os arquivos de pacotes devem seguir essas diretrizes gerais de diretórios:

`/etc` | Arquivos de configuração essenciais para o sistema
`/usr/bin` | Binários de aplicativos
`/usr/sbin` | Binários do sistema
`/usr/lib` | Bibliotecas
`/usr/include` | Arquivos headers
`/usr/lib/{pkg}` | Módulos, plug-ins etc.
`/usr/share/doc/{pkg}` | Documentação de aplicativos
`/usr/share/info` | Arquivos de sistema do GNU Info
`/usr/share/man` | Páginas Man
`/usr/share/{pkg}` | Dados de aplicativos
`/var/lib/{pkg}` | Armazenamento persistente de aplicativos
`/etc/{pkg}` | Arquivos de configuração do `{pkg}`
`/opt/{pkg}` | Pacotes grandes contendo todos os seus arquivos, como o Java, etc.

- Pacotes não devem conter os diretórios abaixo:
  - /dev
  - /home
  - /srv
  - /media
  - /mnt
  - /proc
  - /root
  - /selinux
  - /sys
  - /tmp
  - /var/tmp

## Tarefas do Makepkg

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

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

## Arquiteturas

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

## Licenças

A variável de vetor license está sendo implementada nos repositórios oficiais, e ela deve ser usada em seus pacotes da mesma forma. Use-a da seguinte forma:

- 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')
- Se a licença apropriada não estiver incluída no pacote oficial de licenças, várias coisas devem ser feitas:
  1. 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:

         install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"

  2. 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.
  3. Adicione 'custom' no vetor de licenças. Opcionalmente, você pode substituir 'custom' com 'custom:"nome da licença"'.
- Quando uma licença é usada em um ou mais pacotes no repositório oficial, incluindo [community], ela vira uma licença comum
- 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/.
- 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.
- A (L)GPL tem várias versões e permutações dessas versões. Para softwares (L)GPL, a conveção é:
  - (L)GPL - (L)GPLv2 ou qualquer versão posterior
  - (L)GPL2 - (L)GPL2 somente
  - (L)GPL3 - (L)GPL3 ou qualquer versão posterior

## Enviando pacotes para o AUR

Note o seguinte antes de enviar qualquer pacote para o AUR:

1. 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.
2. Para conferir segurança aos pacotes enviados para o AUR please certifique-se de que você preencheu corretamente o campo de `md5sum`. Os `md5sum`s podem ser gerados usando o comando `makepkg -g`.
3. Por favor adicione uma linha de comentário ao topo do arquivo `PKGBUILD` que siga este formato. Lembre-se de disfarçar seu e-mail para se proteger de spams:

       # 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):

       # Maintainer: Seu Nome <endereço at domínio ponto com>
       # Contributor: Nome Anterior <endereço at domínio ponto com>

4. Verifique as dependências do pacote (p.ex.: execute `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 `namcap`, escrito por Jason Chu, para analisar a sanidade dos pacotes. O `namcap` vai avisar você sobre permissões incorretas, dependências faltando, dependências desnecessárias, e outros erros comuns. Você pode instalar o pacote `namcap` com o `pacman`. Lembre-se de que o `namcap` pode ser usado para verificar tanto os arquivos pkg.tar.gz quanto os PKGBUILDs
5. 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.
6. Não use o `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 `conflicts` (e `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 `replaces` onde quer que esteja nos repositórios; O `conflicts`, por outro lado, será somente avaliado quando se estiver instalado o pacote, que é o comportamento desejado porque é menos invasivo.
7. Todos os arquivos enviados para o AUR devem conter um arquivo tar compactado contendo um diretório com o `PKGBUILD` e arquivos de compilação adicionais (patches, install etc.).

       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 `makepkg --source`. Isso vai criar um tarball chamado `$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

## 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.

### Pacotes de CVS (SVN, GIT, HG etc.)

Por favor, ver as diretrizes de PKGBUILD de CVS do Arch

### Pacotes de plug-ins do Eclipse

Por favor, ver as diretrizes de pacotes de plug-ins do Eclipse

### Pacotes de GNOME

Por favor, ver as diretrizes de pacotes do GNOME

### Pacotes de Go

Por favor, ver as diretrizes de pacotes de Go

### Pacotes de Haskell

Por favor, ver as diretrizes de pacotes de Haskell

### Pacotes de Java

Por favor, ver as diretrizes de pacotes de Java

### Pacotes do KDE

Por favor, ver as diretrizes de pacotes do KDE

### Pacotes de módulos de kernel

Por favor, ver as diretrizes de pacotes de módulos do kernel

### Pacotes de Lisp

Por favor, ver as diretrizes de pacotes de Lisp

### Pacotes de OCaml

Por favor, ver as diretrizes de pacotes de Ocaml

### Pacotes de Perl

Por favor, ver as diretrizes de pacotes de Perl

### Pacotes de Python

Por favor, ver as diretrizes de pacotes de Python

### Pacotes de Ruby Gem

Por favor, ver as diretrizes de pacotes de Ruby Gem

### Pacotes de Wine

Por favor, ver as diretrizes de pacotes de Wine

### Pacotes de MinGW

Por favor, ver as diretrizes de pacotes de MingW

Categories:

- About Arch (Português)
- Package management (Português)
- Package development (Português)