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

From ArchWiki
Jump to: navigation, search
(Directories)
(synchronized interlanguage links with the other wikis)
(10 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 
[[Category:About Arch (Português)]]
 
[[Category:About Arch (Português)]]
[[Category:Package management]]
+
[[Category:Package management (Português)]]
[[Category:Package development]]
+
[[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]]
 +
[[ja:Arch Packaging Standards]]
 
[[ru:Arch Packaging Standards]]
 
[[ru:Arch Packaging Standards]]
 
[[sr:Arch Packaging Standards]]
 
[[sr:Arch Packaging Standards]]
Line 12: Line 13:
 
'''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.'''
 
'''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 [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 a intenção é '''contribuir''' com um novo pacote para o Arch Linux. Você também deveria ler as páginas man 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 ==
Line 117: Line 118:
 
</ul>
 
</ul>
  
{{translateme}}
+
== Diretórios ==
==Directories==
+
 
<ul>
 
<ul>
 
<li>
 
<li>
Line 207: Line 207:
 
</ul>
 
</ul>
  
==Makepkg duties==
+
==Tarefas do Makepkg==
  
 
<p>
 
<p>
When [[makepkg]] is used to build a package, it does the
+
Quando [[makepkg]] é usado para criar um pacote, ele automaticamente faz o seguinte:
following automatically:
+
 
</p>
 
</p>
  
 
<ol>
 
<ol>
 
<li>
 
<li>
Checks if package '''dependencies''' and '''makedepends''' are installed
+
Verifica se as dependências ('''dependencies''') e dependências em tempo de compilação ('''makedepends''') do pacote estão instaladas
 
</li>
 
</li>
 
<li>
 
<li>
'''Downloads source''' files from servers
+
'''Baixar os arquivos fontes''' dos servidores
 
</li>
 
</li>
 
<li>
 
<li>
'''Checks the integrity''' of source files
+
'''Verifica a integridade ''' de arquivos fonte
 
</li>
 
</li>
 
<li>
 
<li>
'''Unpacks''' source files
+
'''Descompacta''' os arquivos fonte
 
</li>
 
</li>
 
<li>
 
<li>
Does any necessary '''patching'''
+
Realiza qualquer '''patch''' necessário
 
</li>
 
</li>
 
<li>
 
<li>
  
'''Builds''' the software and installs it in a fake
+
'''Compila''' o software e instala-o em um fakeroot (ambiente falso)
root
+
 
</li>
 
</li>
 
<li>
 
<li>
'''Strips''' symbols from binaries
+
Remove ('''strips''') símbolos de binários
 
</li>
 
</li>
 
<li>
 
<li>
'''Strips''' debugging symbols from libraries
+
Remove ('''strips''') símbolos de depuração de biblotecas
 
</li>
 
</li>
 
<li>
 
<li>
'''Compresses''' manual and, or info pages
+
'''Compacta''' páginas de manual e/ou info
 
</li>
 
</li>
 
<li>
 
<li>
Generates the '''package meta file''' which is included with each package
+
Gera o '''meta-arquivo de pacote''', o qual é incluído em cada pacote
 
</li>
 
</li>
  
Line 252: Line 250:
 
</li>
 
</li>
 
<li>
 
<li>
'''Stores''' the package file in the configured destination directory (<span title="Current Working Directory" style="border-bottom:1px dotted">cwd</span> by default)
+
'''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>
 
</li>
  
 
</ol>
 
</ol>
  
==Architectures==
+
==Arquiteturas==
The {{Ic|arch}} array should contain {{Ic|'i686'}} and/or {{Ic|'x86_64'}} depending on which architectures it can be built on. You can also use {{Ic|'any'}} for architecture independent packages.
+
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.
  
==Licenses==
+
==Licenças==
The [[Licenses|license]] array is being implemented in the official repos, and it <b>should</b> be used in your packages as well. Use it as follows:
+
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>
 
<ul>
<li>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')</li>
+
<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>If the appropriate license is not included in the official licenses package, several things must be done:
+
<li>Se a licença apropriada não estiver incluída no pacote oficial de licenças, várias coisas devem ser feitas:
 
<ol>
 
<ol>
<li>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:
+
<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"}}
 
{{bc|install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"}}
 
</li>
 
</li>
<li>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.
+
<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>Add 'custom' to the licenses arrayOptionally, you can replace 'custom' with 'custom:"name of license"'.</li>
+
<li>Adicione 'custom' no vetor de licençasOpcionalmente, você pode substituir 'custom' com 'custom:"nome da licença"'.</li>
 
</ol></li>
 
</ol></li>
<li>Once a licenses is used in two or more packages in an official repo, including [community], it becomes common</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>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/.</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>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.</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>The (L)GPL has many versions and permutations of those versions. For (L)GPL software, the convention is:
+
<li>A (L)GPL tem várias versões e permutações dessas versões. Para softwares (L)GPL, a conveção é:
 
<ul>
 
<ul>
<li>(L)GPL - (L)GPLv2 or any later version</li>
+
<li>(L)GPL - (L)GPLv2 ou qualquer versão posterior</li>
<li>(L)GPL2 - (L)GPL2 only</li>
+
<li>(L)GPL2 - (L)GPL2 somente</li>
<li>(L)GPL3 - (L)GPL3 or any later version</li>
+
<li>(L)GPL3 - (L)GPL3 ou qualquer versão posterior</li>
 
</ul>
 
</ul>
 
</li>
 
</li>
 
</ul>
 
</ul>
  
==Submitting packages to the AUR==
+
==Enviando pacotes para o AUR==
<p>Note the following before submitting any packages to the AUR:</p>
+
<p>Note o seguinte antes de enviar qualquer pacote para o AUR:</p>
  
 
<ol>
 
<ol>
 
         <li>
 
         <li>
                 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.
+
                 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.
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.
+
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>
 
<li>
 
<li>
To ensure the security of pkgs submitted to the AUR please '''ensure''' that you have correctly filled the {{ic|md5sum}} fieldThe {{ic|md5sum}}'s can be generated using the {{ic|makepkg -g}} command.
+
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>
 
<li>
 
<li>
Please '''add a comment line''' to the top of the
+
Por favor '''adicione uma linha de comentário''' ao topo do arquivo {{ic|PKGBUILD}} que siga este formato.
{{ic|PKGBUILD}} file that follows this format. Remember to disguise
+
                 Lembre-se de disfarçar seu e-mail para se proteger de spams:
                 your email to protect against spam:
+
  
{{bc|# Maintainer: Your Name <address at domain dot com>}}
+
{{bc|# Maintainer: Seu Nome <endereço at domínio ponto 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:
+
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: Your Name <address at domain dot com>
+
{{bc|# Maintainer: Seu Nome <endereço at domínio ponto com>
# Contributor: Previous Name <address at domain dot com>}}
+
# Contributor: Nome Anterior <endereço at domínio ponto com>}}
  
 
</li>
 
</li>
 
<li>
 
<li>
Verify the package '''dependencies''' (eg, run
+
Verifique as '''dependências''' do pacote (p.ex.: execute
{{ic|ldd}} on dynamic executables, check tools required
+
{{ic|ldd}} nos executáveis dinâmicos, verifique as ferramentas necessárias por scripts, etc).
by scripts, etc).
+
  
The TU team '''strongly''' recommend the use of the
+
A equipe de TUs recomenda '''fortemente''' o uso do utilitário
{{ic|namcap}} utility, written by Jason Chu (jason@archlinux.org), to analyze the
+
{{ic|namcap}}, escrito por [https://www.archlinux.org/fellows/#jason Jason Chu], para analisar a
sanity of packages. {{ic|namcap}} will warn you about
+
sanidade dos pacotes. O {{ic|namcap}} vai avisar você sobre
bad permissions, missing dependencies, un-needed dependencies,
+
permissões incorretas, dependências faltando, dependências desnecessárias,
and other common mistakes. You can install the
+
e outros erros comuns. Você pode instalar o pacote {{ic|namcap}} com o {{ic|pacman}}.
{{ic|namcap}} package with {{ic|pacman}}.
+
  
Remember {{ic|namcap}} can be used to check both pkg.tar.gz files and PKGBUILDs
+
Lembre-se de que o {{ic|namcap}} pode ser usado para verificar tanto os arquivos pkg.tar.gz quanto os PKGBUILDs
 
</li>
 
</li>
<li> '''Dependencies'''
+
<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>
are the most common packaging error. Namcap can help detect them, but
+
<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>
it is not always correct. Verify dependencies by looking at source
+
documentation and the program website. </li>
+
<li>'''Do not use {{Ic|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 {{Ic|conflicts}} (and {{Ic|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 {{Ic|replaces}} anywhere in its repositories; {{Ic|conflicts}} on the other hand is only evaluated when actually installing the package, which is usually the desired behavior because it is less invasive.</li>
+
 
<li>
 
<li>
All files uploaded to the AUR should be contained in a '''compressed tar
+
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.).
file''' containing a directory with the '''{{ic|PKGBUILD}}''' and '''additional build files''' (patches, install, ...) in it.
+
 
{{bc|foo/PKGBUILD
 
{{bc|foo/PKGBUILD
 
foo/foo.install
 
foo/foo.install
 
foo/foo_bar.diff
 
foo/foo_bar.diff
 
foo/foo.rc.conf}}
 
foo/foo.rc.conf}}
The archive name should contain the name of the package
+
O nome do arquivo deve conter o nome do pacote, como, por exemplo, foo.tar.gz.
e.g. foo.tar.gz.
+
  
One can easily build a tarball containing all the required files by using {{Ic|makepkg --source}}. This
+
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.
makes a tarball named {{Ic|$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
+
O tarball '''não pode''' conter o tarball de binário criado pelo makepkg, nem deveria conter a lista de arquivos
 
</li>
 
</li>
  
 
</ol>
 
</ol>
  
==Additional guidelines==
+
== Diretrizes adicionais ==
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.
+
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.
  
===VCS (SVN, GIT, HG, etc) packages===
+
=== Pacotes de CVS (SVN, GIT, HG etc.) ===
Please see the [[Arch CVS & SVN PKGBUILD guidelines|Arch VCS PKGBUILD guidelines]]
+
Por favor, ver as [[Arch CVS & SVN PKGBUILD guidelines|diretrizes de PKGBUILD de CVS do Arch]]
  
===Eclipse plugin packages===
+
=== Pacotes de plug-ins do Eclipse ===
Please see the [[Eclipse plugin package guidelines]]
+
Por favor, ver as [[Eclipse plugin package guidelines|diretrizes de pacotes de plug-ins do Eclipse]]
  
===GNOME packages===
+
=== Pacotes de GNOME ===
Please see the [[GNOME Package Guidelines]]
+
Por favor, ver as [[GNOME Package Guidelines|diretrizes de pacotes do GNOME]]
  
===Go packages===
+
=== Pacotes de Go ===
Please see the [[Go Package Guidelines]]
+
Por favor, ver as [[Go Package Guidelines|diretrizes de pacotes de Go]]
  
===Haskell packages===
+
=== Pacotes de Haskell ===
Please see the [[Haskell package guidelines]]
+
Por favor, ver as [[Haskell package guidelines|diretrizes de pacotes de Haskell]]
  
===Java packages===
+
=== Pacotes de Java ===
Please see the [[Java Package Guidelines]]
+
Por favor, ver as [[Java Package Guidelines|diretrizes de pacotes de Java]]
  
===KDE packages===
+
=== Pacotes do KDE ===
Please see the [[KDE Package Guidelines]]
+
Por favor, ver as [[KDE Package Guidelines|diretrizes de pacotes do KDE]]
  
===Kernel module packages===
+
=== Pacotes de módulos de kernel ===
Please see the [[Kernel Module Package Guidelines]]
+
Por favor, ver as [[Kernel Module Package Guidelines|diretrizes de pacotes de módulos do kernel]]
  
===Lisp packages===
+
=== Pacotes de Lisp ===
Please see the [[Lisp Package Guidelines]]
+
Por favor, ver as [[Lisp Package Guidelines|diretrizes de pacotes de Lisp]]
  
===OCaml packages===
+
=== Pacotes de OCaml ===
Please see the [[OCaml_Package_Guidelines]]
+
Por favor, ver as [[OCaml_Package_Guidelines|diretrizes de pacotes de Ocaml]]
  
===Perl packages===
+
=== Pacotes de Perl ===
Please see the [[Perl Package Guidelines]]
+
Por favor, ver as [[Perl Package Guidelines|diretrizes de pacotes de Perl]]
  
===Python packages===
+
=== Pacotes de Python ===
Please see the [[Python Package Guidelines]]
+
Por favor, ver as [[Python Package Guidelines|diretrizes de pacotes de Python]]
  
===Ruby Gem packages===
+
=== Pacotes de Ruby Gem ===
Please see the [[Ruby Gem Package Guidelines]]
+
Por favor, ver as [[Ruby Gem Package Guidelines|diretrizes de pacotes de Ruby Gem]]
  
===Wine packages===
+
=== Pacotes de Wine ===
Please see the [[Arch wine PKGBUILD guidelines]]
+
Por favor, ver as [[Arch wine PKGBUILD guidelines|diretrizes de pacotes de Wine]]
  
===MinGW packages===
+
=== Pacotes de MinGW===
Please see the [[MinGW PKGBUILD guidelines]]
+
Por favor, ver as [[MinGW PKGBUILD guidelines|diretrizes de pacotes de MingW]]

Revision as of 17:28, 23 February 2014

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 md5sums 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