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
PKGBUILD
s 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')
.
This article or section is a candidate for merging with
Diretrizes de pacotes do Arch
.
Notes:
O formato do PKGBUILD não faz valer a política de empacotamento. (Discuss in
Talk:PKGBUILD
)
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 de uma versão anterior 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