PKGBUILD (Português)

Status de tradução: Esse artigo é uma tradução de PKGBUILD. Data da última tradução: 2023-12-27. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.

Artigos relacionados

• Diretrizes de empacotamento do Arch
• Criando pacotes
• .SRCINFO
• Arch User Repository
• Category:Package development (Português)
• Sistema de compilação do Arch
• makepkg

Esse artigo discute variáveis definíveis pelo mantenedor em um PKGBUILD. Para informações sobre funções do PKGBUILD e criação de pacotes em geral, veja Criando pacotes. Leia também PKGBUILD(5).

Um PKGBUILD é um script shell contendo as informações de compilação necessárias por pacotes do Arch Linux.

Pacotes no Arch Linux são compilados usando o utilitário makepkg. Quando makepkg é executado, ele pesquisa por um arquivo PKGBUILD no diretório atual e segue as instruções dele para compilar ou obter os arquivos para compilar um pacote (pkgname.pkg.tar.zst). O pacote resultante contém arquivos binários e instruções de instalação, prontos para serem instalados com pacman.

Variáveis obrigatórias são pkgname, pkgver, pkgrel e arch. license não é estritamente necessária para compilar um pacote, mas é recomendada para qualquer PKGBUILD compartilhado com outras pessoas, já que makepkg vai produzir um aviso se não estiver presente.

É uma prática comum definir as variáveis no PKGBUILD da mesma forma dadas aqui. Porém, isso não é obrigatório, desde que a sintaxe Bash correta seja usada.

Dica:

• Use namcap para verificar PKGBUILDs por erros comuns de empacotamento.
• termux-language-server^AUR fornece um servidor de idiomas para PKGBUILD, makepkg.conf, etc.

Nome do pacote

pkgbase

Ao compilar pacotes comuns, esta variável não deve ser explicitamente declarada no PKGBUILD: seu valor é padronizado para o do #pkgname.

Ao criar um pacote dividido (split package, em inglês), essa variável pode ser usada para especificar explicitamente o nome a ser usado para se referir ao grupo de pacotes na saída de makepkg e na nomeação de tarballs somente de origem. O valor não é permitido para começar com um hífen. Se não for especificado, o valor será o padrão para o primeiro elemento no vetor pkgname.

Todas opções e diretivas para pacotes divididos têm como padrão os valores globais definidos no PKGBUILD. Mesmo assim, os seguintes podem ser sobrescritos dentro de cada função de empacotameto do pacote dividido: #pkgdesc, #arch, #url, #license, #groups, #depends, #optdepends, #provides, #conflicts, #replaces, #backup, #options, #install e #changelog.

pkgname

O nome do pacote (por exemplo, pkgname='foo') ou, para pacotes divididos, um vetor de nomes (por exemplo, pkgname=('foo' 'bar')). Nomes não podem iniciar com hífenes. Por uma questão de consistência, pkgname deve corresponder ao nome do tarball fonte do software: por exemplo, se o software está em foobar-2.5.tar.gz, use pkgname=foobar.

Versão

pkgver

A versão do pacote. Ela deve ser a mesma que a versão publicada pelo autor do software upstream. Ela pode conter letras, números, pontos e sublinhados, mas não um hífen (-). Se o autor do software usa um hífen, substitua-o com um sublinhado (_). Se a variável pkgver é usada posteriormente no PKGBUILD, então o sublinhado pode ser facilmente substituído por um hífen, ex.: source=("$pkgname-${pkgver//_/-}.tar.gz").

Nota: Se o upstream usa um versionamento com marca de tempo como 30102014, certifique-se de usar a data reversa, i.e. 20141030 (formato ISO 8601). Do contrário, ela não aparecerá como uma versão mais nova

Dica:

• A ordem de valores incomuns pode ser testada com vercmp, que é fornecido pelo pacote pacman.
• makepkg pode atualizar automaticamente essa variável definindo uma função pkgver() no PKGBUILD. Veja Diretrizes de pacotes VCS#A função pkgver() para detalhes.

pkgrel

O número de lançamento. Geralmente é um número inteiro positivo que permite diferenciar entre compilações consecutivas da mesma versão de um pacote. Na medida em que correções e funcionalidades adicionais são adicionadas ao PKGBUILD que influencie no pacote resultante, pkgrel deve ser incrementado em 1. Quando uma nova versão do software é lançada, esse valor deve ser redefinido para 1. Em casos excepcionais, outros formatos podem ser encontrados em uso, como em maior.menor.

epoch

Atenção: epoch só deve ser usado quando absolutamente necessário.

Usado para forçar o pacote a ser visto como mais novo do que uma versão anterior com um epoch menor. Esse valor tem que ser um inteiro não negativo; o padrão é 0. É usado quando o esquema de numeração de versão de um pacote muda (ou é alfanumérico), quebrando a lógica de comparação de versão normal. Por exemplo:

pkgver=5.13
pkgrel=2
epoch=1

1:5.13-2

Veja pacman(8) para mais informações sobre comparações de versão.

Genérica

pkgdesc

A descrição do pacote. É recomendado no máximo 80 caracteres e não deve incluir o nome do pacote em uma forma autorreferenciativa, a menos que o nome do aplicativo seja diferente do nome do pacote. Por exemplo, use pkgdesc="Text editor for X11" em vez de pkgdesc="Nedit is a text editor for X11".

Também é importante usar palavras-chaves com sabedoria para aumentar as chances de aparecer em consultas de pesquisas relevantes.

arch

Um vetor de arquiteturas nas quais o PKGBUILD deve poder ser compilado e funcionar. Arch oferece suporte oficialmente apenas x86_64, mas outros projetos podem oferecer suporte a outras arquiteturas. Por exemplo, Arch Linux 32 fornece suporte a i686 e pentium4, e Arch Linux ARM fornece suporte a armv7h (armv7 hardfloat) e aarch64 (armv8 64-bit).

Há dois tipos de valores que o vetor pode usar:

• arch=('any') indica que o pacote pode ser compilado em uma arquitetura e, após compilado, independe da arquitetura em seu estado compilado (geralmente shell scripts, fontes, tema, muitos tipos de extensões etc.).
• arch=(...) com uma ou mais arquiteturas (exceto any) indica que o pacote pode ser compilado para qualquer uma das arquiteturas especificadas, mas é específico da arquitetura depois de compilado. Para esses pacotes, especifique todas as arquiteturas as quais o PKGBUILD oficialmente possui suporte. Para repositórios oficiais e pacotes AUR, isso significa arch=('x86_64'). Opcionalmente, os pacotes AUR podem optar por ter suporte adicional a outras arquiteturas que sabe-se que funcionam.

A arquitetura alvo pode ser acessada com a variável $CARCH durante uma compilação.

url

A URL do site oficial do software sendo empacotado.

license

Nota: O Arch Linux está atualmente passando por uma transição para identificadores de estilo SPDX. Alguns problemas ainda podem precisar ser resolvidos. Esta seção se concentra no formato SPDX. Se você encontrar algum problema, relate-o e discuta com a comunidade.

A licença sob a qual o software é distribuído. Arch Linux usa Identificadores de licença SPDX. Cada licença deve ter uma entrada correspondente em /usr/share/licenses/.

Para licenças comuns (como 'GPL-3-or-later'), o pacote licenses entrega todos os arquivos correspondentes. O pacote é instalado por padrão, pois é uma dependência do metapacote base, e os arquivos podem ser encontrados em /usr/share/licenses/common/. Basta consultar a licença usando seu identificador de licença SPDX na lista de identificadores SPDX.

Famílias de licenças como BSD ou MIT não são, estritamente falando, uma única licença e cada instância requer um arquivo de licença separado. Na variável license, consulte-as usando um identificador SPDX comum (por exemplo, 'BSD-3-Clause' ou 'MIT'), mas depois forneça o arquivo correspondente como se fosse uma licença personalizada.

Para licenças personalizadas, o identificador deve ser LicenseRef-license-name ou custom:license-name, se não estiverem cobertos pelas famílias comuns mencionadas acima. O texto da licença correspondente deve ser colocado no diretório /usr/share/licenses/pkgname. Para instalar o arquivo, um trecho de código a seguir pode ser usado na seção package():

install -Dm644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE"

Combinar várias licenças ou adicionar exceções deve seguir a sintaxe SPDX. Por exemplo, um pacote lançado sob a GNU/GPL 2.0 ou GNU/LGPL 2.1 poderia usar 'GPL-2.0-or-later OR LGPL-2.1-or-later', enquanto um pacote lançado no Apache 2.0 com exceção LLVM: 'Apache-2.0 WITH LLVM-exception'. Observe que esta deve ser uma única string, portanto, toda a expressão deve ser colocada entre aspas. Até novembro de 2023, lista de exceções SPDX é limitada, então geralmente a rota de licença personalizada deve ser usada.

Se forem encontrados problemas com identificadores SPDX, durante o período de transição usar identificadores antigos – nomes dos diretórios em /usr/share/licenses/common – é aceitável.

Veja também Diretrizes de pacotes de aplicativos não livres (nonfree).

Informações e perspectivas adicionais sobre licenças de software aberto e livre podem ser encontradas nas seguintes páginas:

• Wikipedia:pt:Licença de software livre
• Wikipedia:Comparison of free and open-source software licenses
• A Legal Issues Primer for Open Source and Free Software Projects
• Projeto GNU - Várias licenças e comentários sobre elas
• Debian - License information
• Open Source Initiative - Licenses by Name

groups

O grupo ao qual o pacote pertence. Por exemplo, ao instalar o plasma, ele instala todos os pacotes pertencentes àquele grupo.

Dependências

Nota: Vetores extras específicos por arquitetura podem ser adicionados anexando um sublinhado e o nome da arquitetura. Por exemplo: optdepends_x86_64=().

depends

Um vetor de pacotes que devem ser instalados para o software compilar e executar. Dependências definidas dentro da função package() são necessárias apenas para executar o software.

Restrições de versões podem ser especificadas com operadores de comparação, como, por exemplo, depends=('foobar>=1.8.0'); se múltiplas restrições forem necessárias, a dependência pode ser repetida para cada uma, como, por exemplo, depends=('foobar>=1.8.0' 'foobar<2.0.0').

O vetor depends deve listar todas as dependências diretas de primeiro nível, mesmo quando algumas já são declaradas transitivamente. Por exemplo, se um pacote foo depende de tanto bar quanto baz, e o pacote bar depende de baz também, acabará levando a um comportamento indesejado se bar parar de depender de baz. O pacman não aplicará a instalação de baz em sistemas que instalaram recentemente o pacote foo ou limparam pacotes órfãos, e o foo falhará durante a execução ou se comportará mal.

Em alguns casos, isso não é necessário e pode ou não estar listado, por exemplo, glibc não pode ser desinstalado, pois todo sistema precisa de alguma biblioteca C ou python para um pacote que já depende de outro módulo python-, pois o segundo módulo deve, por definição, depender de python e não pode parar de puxá-lo como uma dependência.

As dependências normalmente devem incluir os requisitos para criar todos os recursos opcionais de um pacote. Como alternativa, qualquer recurso cujas dependências não estejam incluídas deve ser explicitamente desabilitado por meio de uma opção de configuração. A falha em fazer isso pode levar a pacotes com recursos opcionais em tempo de compilação por "dependências automágicas" que são imprevisivelmente ativados devido a dependências transitivas ou softwares não relacionados instalados na máquina de compilação, mas que não são refletidas nas dependências do pacote.

Se o nome da dependência parece ser uma biblioteca, como, por exemplo, depends=('libfoobar.so'), makepkg vai tentar localizar um binário que depende da biblioteca no pacote compilado e anexar a versão de soname necessária pelo binário. Anexar você mesmo a versão desabilita a detecção automática, como, por exemplo, depends=('libfoobar.so=2').

makedepends

Um vetor de pacotes que são necessários apenas para compilar o pacote. A versão mínima de dependência pode ser especificada no mesmo formato que no vetor depends. Os pacotes no vetor depends são implicitamente necessários para compilar o pacote, então eles não devem ser duplicados aqui.

Nota:

• Presume-se que o pacote base-devel já esteja instalado ao compilar com makepkg. As dependências deste pacote não devem ser incluídas no vetor makedepends.
• Se estiver usando Fontes VCS, não se esqueça de incluir a ferramenta VCS apropriada (git, subversion, cvs , ...).

Dica: Você pode usar pactree -rsud1 pacotes | grep base-devel para verificar se um pacote específico é uma dependência direta de base-devel (requer pacman-contrib).

checkdepends

Um vetor de pacotes dos quais o software depende para executar sua suíte de testes, mas que não são necessários em tempo de execução. Pacotes nesta lista seguem o mesmo formato que depends. Essas dependências são consideradas apenas quando a função check() estiver presente e for ser executada pelo makepkg.

Nota: Presume-se que o pacote base-devel já esteja instalado ao compilar com makepkg. As dependências deste pacote não devem ser incluídas no vetor checkdepends.

optdepends

Um vetor de pacotes que não são necessários pelo software para funcionar, mas fornecem funcionalidades adicionais. Isso pode implicar em nem todos os executáveis fornecidos por um pacote funcionarem sem a respectiva optdepends. [1] Se o software funciona em múltiplas dependências alternativas, todas elas podem ser listadas aqui, em vez de no vetor depends.

Uma descrição curta da funcionalidade extra de cada optdepend também deve ser anotado:

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')

Relações do pacote

Nota: Vetores extras específicos por arquitetura podem ser adicionados anexando um sublinhado e o nome da arquitetura. Por exemplo: conflicts_x86_64=().

provides

Um vetor de pacotes adicionais dos quais o software fornece as funcionalidades, incluindo pacotes virtuais como cron ou sh e todas as bibliotecas externas compartilhadas. Pacotes fornecendo o mesmo item podem ser instalados lado a lado, a menos que um deles use um vetor conflicts.

Nota: A versão que aquele pacote fornece deve ser mencionada (pkgver e potencialmente o pkgrel), no caso de pacotes referenciando software que exigem uma. Por exemplo, um pacote modificado do qt na versão 3.3.8, chamado qt-foobar, deve usar provides=('qt=3.3.8'); omitir o número de versão causaria as dependências a exigir uma versão específica do qt falharia. Não adicione pkgname ao vetor provides, pois isso é feito automaticamente.

conflicts

Um vetor de pacotes que conflitam com, ou causam problemas com o pacote, se instalados. Todos esses pacotes e pacotes fornecendo este item precisarão ser removidos. As propriedades da versão dos pacotes conflitantes também podem ser especificados no mesmo formato que o vetor depends.

Observe que os conflitos são verificados em relação a pkgname, bem como os nomes especificados no vetor provides. Portanto, se seu pacote fornecer um recurso foo, especificar foo no vetor conflicts causará um conflito entre seu pacote e todos os outros pacotes que contenham foo em seu vetor provides (ou seja, você não precisa especificar todos esses nomes de pacotes conflitantes em seu vetor conflicts). Vejamos um exemplo concreto:

• netbeans fornece implicitamente netbeans como o pkgname em si
• netbeans-cpp^{AUR[link quebrado: package not found]} fornece netbeans e conflita com netbeans
• netbeans-php^{AUR[link quebrado: package not found]} fornece netbeans e conflita com netbeans, mas não precisa explicitamente conflitar com netbeans-cpp^{AUR[link quebrado: package not found]} já que os pacotes fornecendo os mesmos recursos estão implicitamente em conflito

Quando os pacotes fornecem o mesmo recurso por meio do vetor provides, há uma diferença entre adicionar explicitamente o pacote alternativo ao vetor conflicts e não adicioná-lo. Se o vetor conflicts for declarado explicitamente, os dois pacotes que fornecem o mesmo recurso serão considerados como alternativa; se o vetor conflicts estiver faltando, os dois pacotes que fornecem o mesmo recurso serão considerados como possivelmente coabitando. Os empacotadores devem sempre ignorar o conteúdo da variável provides ao decidir se devem ou não declarar uma variável conflicts.

replaces

Um vetor de pacotes obsoletos que são substituídos pelo pacote, como, por exemplo, wireshark-qt usa replaces=('wireshark'). Ao sincronizar, o pacman vai imediatamente substituir um pacote instalado ao encontrar outro pelo replaces correspondente nos repositórios. Se estiver fornecendo uma versão alternativa de um pacote já existente ou enviando para o AUR, use os vetores conflicts e provides, que são avaliados apenas ao instalar o pacote conflitante.

Outros

backup

Um vetor de arquivos que contêm alterações feitas pelo usuário e, portanto, devem ser preservados durante a atualização ou remoção de um pacote, destinado principalmente para arquivos em /etc.

Arquivos neste vetor devem usar caminhos relativos sem a barra inicial (/) (ex.: etc/pacman.conf, em vez de /etc/pacman.conf).

Ao atualizar, novas versões podem ser salvadas como arquivo.pacnew para evitar sobrescrever um arquivo que já existe e foi previamente modificado pelo usuário. De forma similar, quando o pacote é removido, os arquivos modificados pelo usuário serão preservados como arquivo.pacsave a menos que o pacote tenha sido removido com o comando pacman -Rn.

Veja também os arquivos Pacnew e Pacsave.

options

Esse vetor permite sobrescrever alguns dos comportamentos padrões do makepkg, definidos no /etc/makepkg.conf. Para definir uma opção, inclua o nome no vetor. Para inverter o comportamento, coloque um ! na frente.

A lista completa das opções disponíveis podem ser localizadas em PKGBUILD(5) § OPTIONS AND DIRECTIVES.

install

O nome do script .install a ser incluído no pacote.

pacman possui a capacidade de armazenar e executar um script específico por pacote durante a instalação, remoção ou atualização de um pacote. O script contém as seguintes funções que são executadas em momentos diferentes:

• pre_install — O script é executado logo antes dos arquivos serem extraídos. Um argumento é passado: nova versão do pacote.
• post_install — O script é executado logo após os arquivos serem extraídos. Um argumento é passado: nova versão do pacote.
• pre_upgrade — O script é executado logo antes dos arquivos serem extraídos. Dois argumentos são passados na seguinte ordem: nova versão do pacote, versão antiga do pacote.
• post_upgrade — O script é executado logo após os arquivos serem extraídos. Dois argumentos são passados na seguinte ordem: nova versão do pacote, versão antiga do pacote.
• pre_remove — O script é executado logo antes dos arquivos serem removidos. Um argumento é passado: versão antiga do pacote.
• post_remove — O script é executado logo após os arquivos serem removidos. Um argumento é passado: versão antiga do pacote.

Cada função é executada em chroot dentro do diretório de instalação do pacman. Veja esse tópico.

Dica:

• Um protótipo de .install é fornecido em /usr/share/pacman/proto.install.
• Hooks do pacman fornecem funcionalidade similar.

Nota: Não termine o script com exit. Isso evitaria as funções contidas de serem executadas.

changelog

O nome do changelog do pacote. Para ver os registros de alterações de pacotes instalados (que tenha esse arquivo):

$ pacman -Qc pkgname

Fontes

source

Um vetor de arquivos necessários para compilar o pacote. Deve conter a localização do fonte do software, que na maioria dos casos é uma URL HTTP ou FTP completa. As variáveis anteriormente definidas pkgname e pkgver podem ser usadas efetivamente aqui como, por exemplo, source=("https://exemplo.com/$pkgname-$pkgver.tar.gz").

Os arquivos também podem ser fornecidos no mesmo diretório onde o PKGBUILD está localizado, e seus nomes adicionados a este vetor. Antes do processo de compilação iniciar, todos os arquivos referenciados neste vetor serão baixados ou verificados pela existência, e o makepkg não dará continuidade, se algum deles estiver faltando.

Arquivos .install são reconhecidos automaticamente pelo makepkg e não devem ser incluídos no vetor source. Arquivos no vetor source com extensões .sig, .sign ou .asc são reconhecidos pelo makepkg como assinaturas PGP e serão usados automaticamente para verificar a integridade do arquivo fonte correspondente.

Atenção: Os nomes de arquivos de fontes baixados devem ser globalmente únicos porque o diretório SRCDEST pode ser o mesmo para todos pacotes. Por exemplo, usar o número de versão do projeto como um nome de arquivo potencialmente conflita com outros projetos com o mesmo número de versão. Neste caso, o nome de arquivo único alternativo a ser usado é fornecido com a sintaxe source=('nome_pacote_único::uri_arquivo') - por exemplo, source=("$pkgname-$pkgver.tar.gz::https://github.com/codificador/programa/archive/v$pkgver.tar.gz").

Dica:

• Vetores extras específicos por arquitetura podem ser adicionados anexando um sublinhado e o nome da arquitetura, ex.: x86_64=(). Deve haver um vetor de integridade correspondente com somas de verificação (checksums), ex.: sha256sums_x86_64=().
• Alguns servidores restringem download filtrando a string "User-Agent" do cliente ou com outros tipos de restrições, o que pode ser alterado com DLAGENTS.
• Você pode usar a URL file:// para apontar para um diretório ou arquivo no sistema de arquivos do seu computador. Por exemplo, um repositório Git local pode ser especificado como "$pkgname"::"git+file:///caminho/para/o/repositório".
• Suporte para link magnético pode ser adicionado usando transmission-dlagent^AUR como DLAGENT e usando o prefixo uri magnet:// em vez do prefixo uri canônico magnet:?.
• Consulte PKGBUILD(5) § USING VCS SOURCES e Diretrizes de pacotes VCS#Fontes VCS para obter detalhes sobre opções específicas de VCS, como direcionar um branch ou commit específico do Git.

noextract

Um vetor de arquivos listados sob source que não devem ser extraídos de seu formato empacotado pelo makepkg. Isso pode ser usado com pacotes que não podem ser tratados pelo /usr/bin/bsdtar ou aqueles que precisam ser instalado como estão. Se uma ferramenta alternativa de extração for usada (e.g. lrzip), ela deve ser adicionada no vetor makedepends e a primeira linha da função prepare() deve extrair manualmente o pacote fonte; por exemplo:

prepare() {
  lrzip -d source.tar.lrz
}

Note que enquanto o vetor source aceita URLs, noextract é apenas a porção de nome do arquivo:

source=("http://foo.org/bar/foobar.tar.xz")
noextract=('foobar.tar.xz')

Para extrair nada, você pode fazer alguma coisa como:

• Se source contém apenas URLs planas sem nomes de arquivos personalizados, remova do vetor source antes da última barra:

noextract=("${source[@]##*/}")

• Se source contiver apenas entradas com nomes de arquivos personalizados, remova do vetor source o conteúdo após o separador :: (retirado do PKGBUILD do firefox-i18n):

noextract=("${source[@]%%::*}")

validpgpkeys

Um vetor de impressões digitais PGP. Se usado, makepkg só aceitará assinaturas das chaves listadas aqui e vai ignorar os valores de confiança do chaveiro. Se o arquivo fonte foi assinado com uma subchave, makepkg ainda vai usar a chave primária para comparação.

Apenas impressões digitais completas são aceitas. Elas devem estar em caixa alta e não devem conter caracteres em branco.

Nota: Você pode usar gpg --list-keys --fingerprint ID-CHAVE para localizar a impressão digital da chave apropriada.

Por favor, leia makepkg (Português)#Verificação de assinatura para mais informações.

Integridade

Essas variáveis são vetores cujos itens são strings de checksums (soma de verificação) que serão usadas para verificar a integridade dos respectivos arquivos no vetor source. Você também pode inserir SKIP para um arquivo em particular e seu checksum não será testado.

O tipo e os valores da soma de verificação (checksum) devem ser sempre aqueles fornecidos pelo upstream, como nos anúncios de lançamento. Quando vários tipos estão disponíveis, a soma de verificação mais forte deve ser preferida: b2 à sha512, sha512 à sha384, sha384 à sha256, sha256 à sha224, sha224 à sha1, sha1 à md5 e md5 à ck. Isso garante a integridade dos arquivos baixados, desde o anúncio do upstream até o desenvolvimento de pacotes.

Nota: Além disso, quando o upstream disponibiliza assinaturas digitais, os arquivos de assinatura devem ser adicionados ao vetor source e a impressão digital da chave PGP ao vetor validpgpkeys. Isso permite a autenticação dos arquivos no momento de compilação.

Os valores para essas variáveis podem ser geradas automaticamente pela opção -g/--geninteg do makepkg e, então, anexado com makepkg -g >> PKGBUILD. O comando updpkgsums(8) do pacman-contrib é capaz de atualizar as variáveis onde quer que elas estejam no PKGBUILD. Ambas ferramentas usarão a variável que já está definida no PKGBUILD, ou voltarão para md5sums se nada estiver definido.

As verificações de integridade de arquivo a serem usadas podem ser configuradas com a opção INTEGRITY_CHECK no /etc/makepkg.conf. Veja makepkg.conf(5).

Nota: Vetores adicionais específicos da arquitetura podem ser adicionadas anexando um sublinhado e o nome da arquitetura, p. ex. sha256sums_x86_64=().

cksums

Um vetor de checksums CRC32 (do cksum padrão do UNIX) de arquivos listados no vetor source.

md5sums

Um vetor de checksums de MD5 de 128 bits dos arquivos listados no vetor source.

sha1sums

Um vetor de checksums de SHA-1 de 160 bits dos arquivos listados no vetor source.

sha256sums

Um vetor de checksums de SHA-2 com tamanho de digest de 256 bits.

sha224sums, sha384sums, sha512sums

Um vetor de checksums de SHA-2 com tamanhos de digest 224, 384 e 512 bits, respectivamente. Essas são alternativas mais comuns a sha256sums.

b2sums

Um vetor de checksums de BLAKE2 com tamanho de digest de 512 bits.

Veja também

• PKGBUILD(5) - página de manual do PKGBUILD
• Exemplo de arquivo PKGBUILD