Arch packaging standards (Português)

From ArchWiki
Revision as of 03:39, 18 October 2012 by Josephgbr (Talk | contribs) (Makepkg duties)

Jump to: navigation, search

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.

Tango-preferences-desktop-locale.pngThis article or section needs to be translated.Tango-preferences-desktop-locale.png

Notes: please use the first argument of the template to provide more detailed indications. (Discuss in Talk:Arch packaging standards (Português)#)

Directories

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

Licenses

The license array is being implemented in the official repos, and it should be used in your packages as well. Use it as follows:

  • A licenses package has been created in [core] that stores common licenses in /usr/share/licenses/common ie. /usr/share/licenses/common/GPL. If a package is licensed under one of these licenses, the licenses variable will be set to the directory name e.g. license=('GPL')
  • If the appropriate license is not included in the official licenses package, several things must be done:
    1. The license file(s) should be included in /usr/share/licenses/$pkgname/ e.g. /usr/share/licenses/dibfoo/LICENSE. One good way to do this is by using:
      install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
    2. If the source tarball does NOT contain the license details and the license is only displayed on a website for example, then copy the license to a file and include it. Remember to call it something appropriate too.
    3. Add 'custom' to the licenses array. Optionally, you can replace 'custom' with 'custom:"name of license"'.
  • Once a licenses is used in two or more packages in an official repo, including [community], it becomes common
  • The MIT, BSD, zlib/libpng and Python licenses are special cases and cannot be included in the 'common' licenses pkg. For the sake of the license variable, it is treated like a common license (license=('BSD'), license=('MIT'), license=('ZLIB') or license=('Python')) but for the sake of the filesystem, it is a custom license, because each one has its own copyright line. Each MIT, BSD, zlib/libpng or Python licensed package should have its unique license stored in /usr/share/licenses/$pkgname/.
  • Some packages may not be covered by a single license. In these cases multiple entries may be made in the license array e.g. license=("GPL" "custom:some commercial license"). For the majority of packages these licenses apply in different cases, as opposed to applying at the same time. When pacman gets the ability to filter on licenses (so you can say, "I only want GPL and BSD licensed software") dual (or more) licenses will be treated by pacman using OR, rather than AND logic, thus pacman will consider the above example as GPL licensed software, regardless of the other licenses listed.
  • The (L)GPL has many versions and permutations of those versions. For (L)GPL software, the convention is:
    • (L)GPL - (L)GPLv2 or any later version
    • (L)GPL2 - (L)GPL2 only
    • (L)GPL3 - (L)GPL3 or any later version

Submitting packages to the AUR

Note the following before submitting any packages to the AUR:

  1. The submitted PKGBUILDs MUST NOT build applications already in any of the official binary repositories under any circumstances. Exception to this strict rule may only be packages having extra features enabled and/or patches in compare to the official ones. In such an occasion the pkgname array should be different to express that difference. eg. A GNU screen PKGBUILD submitted containing the sidebar patch, could be named screen-sidebar etc. Additionally the provides=('screen') PKGBUILD array should be used in order to avoid conflicts with the official package.
  2. To ensure the security of pkgs submitted to the AUR please ensure that you have correctly filled the md5sum field. The md5sum's can be generated using the makepkg -g command.
  3. Please add a comment line to the top of the PKGBUILD file that follows this format. Remember to disguise your email to protect against spam:
    # Maintainer: Your Name <address at domain dot com>

    If you are assuming the role of maintainer for an existing PKGBUILD, add your name to the top as described above and change the title of the previous Maintainer(s) to Contributor:

    # Maintainer: Your Name <address at domain dot com>
    # Contributor: Previous Name <address at domain dot com>
  4. Verify the package dependencies (eg, run ldd on dynamic executables, check tools required by scripts, etc). The TU team strongly recommend the use of the namcap utility, written by Jason Chu (jason@archlinux.org), to analyze the sanity of packages. namcap will warn you about bad permissions, missing dependencies, un-needed dependencies, and other common mistakes. You can install the namcap package with pacman. Remember namcap can be used to check both pkg.tar.gz files and PKGBUILDs
  5. Dependencies are the most common packaging error. Namcap can help detect them, but it is not always correct. Verify dependencies by looking at source documentation and the program website.
  6. Do not use replaces in a PKGBUILD unless the package is to be renamed, for example when Ethereal became Wireshark. If the package is an alternate version of an already existing package, use conflicts (and provides if that package is required by others). The main difference is: after syncing (-Sy) pacman immediately wants to replace an installed, 'offending' package upon encountering a package with the matching replaces anywhere in its repositories; conflicts on the other hand is only evaluated when actually installing the package, which is usually the desired behavior because it is less invasive.
  7. All files uploaded to the AUR should be contained in a compressed tar file containing a directory with the PKGBUILD and additional build files (patches, install, ...) in it.
    foo/PKGBUILD
    foo/foo.install
    foo/foo_bar.diff
    foo/foo.rc.conf

    The archive name should contain the name of the package e.g. foo.tar.gz.

    One can easily build a tarball containing all the required files by using makepkg --source. This makes a tarball named $pkgname-$pkgver-$pkgrel.src.tar.gz, which can then be uploaded to the AUR.

    The tarball should not contain the binary tarball created by makepkg, nor should it contain the filelist

Additional guidelines

Be sure to read the above guidelines first - important points are listed on this page that will not be repeated in the following guideline pages. These specific guidelines are intended as an addition to the standards listed on this page.

VCS (SVN, GIT, HG, etc) packages

Please see the Arch VCS PKGBUILD guidelines

Eclipse plugin packages

Please see the Eclipse plugin package guidelines

GNOME packages

Please see the GNOME Package Guidelines

Go packages

Please see the Go Package Guidelines

Haskell packages

Please see the Haskell package guidelines

Java packages

Please see the Java Package Guidelines

KDE packages

Please see the KDE Package Guidelines

Kernel module packages

Please see the Kernel Module Package Guidelines

Lisp packages

Please see the Lisp Package Guidelines

OCaml packages

Please see the OCaml_Package_Guidelines

Perl packages

Please see the Perl Package Guidelines

Python packages

Please see the Python Package Guidelines

Ruby Gem packages

Please see the Ruby Gem Package Guidelines

Wine packages

Please see the Arch wine PKGBUILD guidelines

MinGW packages

Please see the MinGW PKGBUILD guidelines