PKGBUILD (Español)

Esta traducción de
PKGBUILD
fue revisada el
2022-11-02
. Si existen
cambios
puede
actualizarla
o avisar al
equipo de traducción
.
Artículos relacionados
Directrices del paquete de Arch
Crear paquetes
.SRCINFO
Repositorio de usuarios de Arch
Categoría:Desarrollo de paquetes
Sistema de construcción de Arch
makepkg
Este artículo analiza las variables definibles por el mantenedor en un
PKGBUILD
. Para obtener información sobre las funciones
PKGBUILD
y la creación de paquetes en general, véase
Crear paquetes
. Véase también
PKGBUILD(5)
.
Un
PKGBUILD
es un script de intérprete de línea de órdenes que contiene la información de compilación requerida por los paquetes de
Arch Linux
.
Los paquetes en Arch Linux se construyen utilizando la utilidad
makepkg
. Cuando se ejecuta
makepkg
, busca un archivo
PKGBUILD
en el directorio actual y sigue las instrucciones para compilar o adquirir los archivos para crear un archivo de paquete (
pkgname
.pkg.tar.zst
). El paquete resultante contiene archivos binarios e instrucciones de instalación, fácilmente instalables con
pacman
.
Las variables obligatorias son
pkgname
,
pkgver
,
pkgrel
y
arch
.
license
no es estrictamente necesario para construir un paquete, pero se recomienda para cualquier
PKGBUILD
compartido con otros, ya que
makepkg
generará una advertencia si no está presente.
Es una práctica común definir las variables en
PKGBUILD
en el mismo orden que se indica aquí. Sin embargo, esto no es obligatorio, siempre que se utilice la sintaxis
Bash
correcta.
Sugerencia
Utilice
namcap
para verificar los errores más comunes de empaquetado en los
PKGBUILD
.
Nombre del paquete
pkgbase
Al crear paquetes normales, esta variable no debe declararse explícitamente en
PKGBUILD
: su valor predeterminado es el de
#pkgname
.
Al construir un
paquete dividido
, esta variable se puede utilizar para especificar explícitamente el nombre que se utilizará para referirse al grupo de paquetes en la salida de
makepkg
y en la denominación de las fuentes tarballs. No se permite que el valor comience con un guión. Si no se especifica, el valor predeterminado será el primer elemento de la matriz
pkgname
.
Todas las opciones y directivas para paquetes divididos tienen por defecto los valores globales dados en
PKGBUILD
. Sin embargo, los siguientes pueden anularse dentro de la función de empaquetado de cada paquete dividido:
#pkgdesc
,
#arch
,
#url
,
#license
,
#groups
,
#depends
,
#optdepends
,
#provides
,
#conflicts
,
#replaces
,
#backup
,
#options
,
#install
y
#changelog
.
pkgname
El nombre del paquete, por ejemplo
pkgname='foo'
, o para paquetes divididos una matriz de nombres, por ejemplo
pkgname=('foo' 'bar')
. Los nombres de los paquetes solo deben constar de letras alfanuméricas en minúsculas y los siguientes caracteres:
@._+-
(símbolo de arroba, punto, guión bajo, signo más, guión). No se permite que los nombres comiencen con guiones o puntos. En aras de la coherencia,
pkgname
debe coincidir con el nombre del tarball fuente del software: por ejemplo, si el software está en
foobar-2.5.tar.gz
, utilice
pkgname=foobar
.
Versión
pkgver
La versión del paquete. Esta debe ser la misma que la versión publicada por el autor del software original. Puede contener letras, números, puntos y guiones bajos, pero
no
un guión (
-
). Si el autor del software utiliza uno, reemplácelo con un guión bajo (
_
). Si la variable
pkgver
se utiliza más tarde en
PKGBUILD
, el guión bajo se puede sustituir fácilmente por un guión, por ejemplo
source=("$pkgname-${pkgver//_/-}.tar.gz")
.
Nota
Si en el
upstream
se utiliza un control de versiones de marca de tiempo como
30102014
, asegúrese de utilizar la fecha invertida, es decir,
20141030
(formato
ISO 8601
). De lo contrario, no aparecerá como una versión más nueva.
Sugerencia
El orden de los valores poco comunes se puede probar con
vercmp(8)
, que proporciona el paquete
pacman
.
makepkg
puede
actualizar
automáticamente esta variable definiendo una función
pkgver()
en el
PKGBUILD
. Véase
VCS package guidelines#The pkgver() function
para obtener más información.
pkgrel
El número de lanzamiento. Suele ser un número entero positivo que permite diferenciar entre compilaciones consecutivas de la misma versión de un paquete. A medida que se añaden correcciones y características adicionales al
PKGBUILD
que influyen en el paquete resultante, el
pkgrel
debe incrementarse en 1. Cuando se lanza una nueva versión del software, este valor debe ser restablecido a 1. En casos excepcionales, se pueden encontrar otros formatos en uso, como
mayor.menor
.
epoch
Advertencia
epoch
solo debe utilizarse cuando sea absolutamente necesario.
Se utiliza para forzar que el paquete se vea como más nuevo que cualquier versión anterior con una época anterior. Se requiere que este valor sea un número entero no negativo; el valor predeterminado es 0. Se utiliza cuando cambia el esquema de numeración de versiones de un paquete (o es alfanumérico), rompiendo la lógica normal de comparación de versiones. Por ejemplo:
pkgver=5.13
pkgrel=2
epoch=1
1:5.13-2
Véase
pacman(8)
para obtener más información sobre las comparaciones de versiones.
Genérico
pkgdesc
La descripción del paquete. Se recomienda que tenga 80 caracteres o menos y no debe incluir el nombre del paquete como autorreferencia, a menos que el nombre de la aplicación sea diferente del nombre del paquete. Por ejemplo, utilice
pkgdesc="Editor de texto para X11"
en lugar de
pkgdesc="Nedit es un editor de texto para X11"
.
También es importante utilizar las palabras clave con prudencia para aumentar las posibilidades de aparecer en consultas de búsqueda relevantes.
arch
Una matriz de arquitecturas que
PKGBUILD
pretende construir y trabajar. Arch admite oficialmente solo
x86_64
, pero otros proyectos pueden admitir otras arquitecturas. Por ejemplo,
Arch Linux 32
brinda soporte para
i686
y
pentium4
y
Arch Linux ARM
brinda soporte para
armv7h
(armv7 hardfloat) y
aarch64
(armv8 de 64 bits).
Hay dos tipos de valores que la matriz puede utilizar:
arch=('any')
indica que el paquete se puede construir una vez en cualquier arquitectura y, una vez construido, es independiente de la arquitectura en su estado compilado (scripts de shell, fuentes, temas, muchos tipos de extensiones, etc).
arch=('x86_64')
con una o más arquitecturas indica que el paquete se puede compilar para cualquiera de las arquitecturas especificadas, pero es específico de la arquitectura una vez compilado. Para estos paquetes, especifique todas las arquitecturas que admite
PKGBUILD
oficialmente. Para repositorios oficiales y paquetes AUR, esto significa
x86_64
. Opcionalmente, los paquetes AUR pueden optar por admitir otras arquitecturas conocidas que funcionen.
Se puede acceder a la arquitectura de destino con la variable
$CARCH
durante una compilación.
url
La URL del sitio oficial del software que se empaqueta.
license
La licencia bajo la cual se distribuye el software. El paquete
licenses
(una dependencia del
metapaquete
base
) contiene muchas licencias de uso común, que se instalan bajo
/usr/share/licenses/common/
. Si un paquete tiene una de estas licencias, el valor debe establecerse en el nombre del directorio, por ejemplo
license=('GPL')
. Si no se incluye la licencia correspondiente, se deben hacer varias cosas:
Añadir
custom
a la matriz
license
. Opcionalmente, puede reemplazar
custom
con
custom:
nombre de la licencia
. Una vez que una licencia se utiliza en dos o más paquetes en un
repositorio oficial
, se convierte en parte del paquete
licenses
.
Instalar la licencia en:
/usr/share/licenses/
pkgname
/
, por ejemplo
/usr/share/licenses/foobar/LICENSE
. Una buena forma de hacerlo es utilizando:
install -Dm644 LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
Si la licencia solo se encuentra en un sitio web, debe incluirla por separado en el paquete.
Las licencias
BSD
,
ISC
,
MIT
,
zlib/png
,
Python
y
OFL
son casos especiales y no se pueden incluir en el paquete
licenses
, debido a que incluyen avisos de derechos de autor
[1]
. Por el bien de la matriz
license
, se trata como una licencia común (
license=('BSD')
,
license=('ISC')
,
license=('MIT')
,
license=('ZLIB')
,
license=('Python')
y
license=('OFL')
), pero técnicamente cada una es una licencia personalizada, porque cada una tiene su propia línea de derechos de autor. Cualquier paquete con licencia bajo estas cinco debe tener su propio archivo de licencia único almacenado en
/usr/share/licenses/
nombrepaquete
/
.
Es posible que algunos paquetes no estén cubiertos por una sola licencia. En estos casos, se pueden realizar varias entradas en la matriz
license
, por ejemplo
license=('GPL' 'custom:
nombre de la licencia'
)
.
(L)GPL tiene muchas versiones y permutaciones de esas versiones. Para el software (L)GPL, la convención es:
(L)GPL — (L)GPLv2 o cualquier versión posterior
(L)GPL2 — (L)GPL2 únicamente
(L)GPL3 — (L)GPL3 o cualquier versión posterior
Si después de investigar el problema no se puede determinar la licencia,
PKGBUILD.proto
sugiere utilizar
unknown
. Sin embargo, se debe contactar a
upstream
sobre las condiciones bajo las cuales el software está (y no está) disponible.
Sugerencia
Algunos autores de software no proporcionan un archivo de licencia separado y describen las reglas de distribución en la sección de
ReadMe.txt
común. Esta información se puede extraer a un archivo separado durante
build()
con algo como
sed -n '/
This software
/,/
thereof.
/p' ReadMe.txt > LICENSE
Véase también
Nonfree applications package guidelines
.
Puede encontrar información adicional y perspectivas sobre las licencias de software libre y de código abierto en las siguientes páginas:
Wikipedia:es:Licencia de software libre
Wikipedia:es:Anexo:Comparación de licencias de software libre
Un manual básico de cuestiones legales para proyectos de código abierto y software libre
Proyecto GNU - Varias licencias y comentarios sobre ellas
Debian - Información de licencias
Iniciativa de código abierto - Licencias por nombre
groups
El
grupo
al que pertenece el paquete. Por ejemplo, al instalar
plasma
, instala todos los paquetes que pertenecen a ese grupo.
Dependencias
Nota
Se pueden añadir matrices adicionales específicas de la arquitectura agregando un guión bajo y el nombre de la arquitectura, por ejemplo
optdepends_x86_64=()
.
depends
Una serie de paquetes que deben instalarse para que el software se compile
y
se ejecute. Las dependencias definidas dentro de la función
package()
solo son necesarias para ejecutar el software.
Las restricciones de versión se pueden especificar con operadores de comparación, por ejemplo
depende=('foobar>=1.8.0')
; si se necesitan múltiples restricciones, la dependencia se puede repetir para cada una, por ejemplo
depende=('foobar>=1.8.0' 'foobar<2.0.0')
.
La matriz
depends
debe listar todas las dependencias directas de primer nivel, incluso cuando algunas ya están declaradas de forma transitiva. Por ejemplo, si un paquete
foo
depende tanto de
bar
como de
baz
, y el paquete
bar
también depende a su vez de
baz
, en última instancia conducirá a Comportamiento no deseado si
bar
deja de tirar de
baz
. Pacman no impondrá la instalación de
baz
en sistemas que hayan instalado recientemente el paquete
foo
, o que hayan limpiado paquetes huérfanos, y
foo
fallará durante el tiempo de ejecución o se comportará mal.
En algunos casos, esto no es necesario y puede o no aparecer en la lista, por ejemplo
glibc
no se puede desinstalar ya que todos los sistemas necesitan alguna biblioteca C, o
python
para un paquete que ya depende de otro módulo
python-
, ya que el segundo módulo debe, por definición, depender de
python
y nunca puede dejar de incorporarlo como una dependencia.
Las dependencias normalmente deberían incluir los requisitos para construir todas las características opcionales de un paquete. Alternativamente, cualquier función cuyas dependencias no estén incluidas debe desactivarse explícitamente a través de una opción de configuración. Si no se hace esto, se pueden generar paquetes con características opcionales en tiempo de compilación "
dependencias automágicas
" que se activan de manera impredecible debido a dependencias transitivas o software no relacionado instalado en la máquina de compilación, pero que no se reflejan en las dependencias del paquete.
Si el nombre de la dependencia parece ser una biblioteca, por ejemplo
depends=('libfoobar.so')
,
makepkg
intentará encontrar un binario que dependa de la biblioteca en el paquete creado y añadirá la versión de
soname
que necesita el binario. Añadir la versión usted mismo desactiva la detección automática, por ejemplo
depende=('libfoobar.so=2')
.
makedepends
Una matriz de paquetes que
solo
se requieren para construir el software. La versión de dependencia mínima se puede especificar en el mismo formato que en la matriz
depends
. Los paquetes en la matriz
depends
se requieren implícitamente para construir el paquete, no deben duplicarse aquí.
Sugerencia
Lo siguiente se puede utilizar para verificar si un paquete en particular está en el grupo
base-devel
o si lo extrae un miembro del grupo:
$ LC_ALL=C pacman -Si $(pactree -rl
paquete
) 2>/dev/null | grep -q "^Groups *:.*base-devel"
Nota
Se supone que el grupo
base-devel
ya está instalado cuando se construye con
makepkg
. Los miembros de este grupo
no deberían
incluirse en la matriz
makedepends
.
checkdepends
Una matriz de paquetes de los que depende el software para ejecutar su conjunto de pruebas, pero que no son necesarios en tiempo de ejecución. Los paquetes de esta lista siguen el mismo formato que
depends
. Estas dependencias solo se consideran cuando la función
check()
está presente y debe ser ejecutada por
makepkg
.
Nota
Se supone que el grupo
base-devel
ya está instalado cuando se construye con
makepkg
. Los miembros de este grupo
no deberían
incluirse en la matriz
checkdepends
.
optdepends
Una serie de paquetes que no son necesarios para que el software funcione, pero que proporcionan funciones adicionales. Esto puede implicar que no todos los ejecutables proporcionados por un paquete funcionarán sin los respectivos optdepends.
[2]
Si el software funciona en múltiples dependencias alternativas, todas ellas se pueden listar aquí, en lugar de la matriz
depends
.
También se debe tener en cuenta una breve descripción de la funcionalidad adicional que proporciona cada optdepend:
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')
Relaciones de paquetes
Nota
Se pueden añadir matrices adicionales específicas de la arquitectura agregando un guión bajo y el nombre de la arquitectura, por ejemplo
conflictos_x86_64=()
.
provides
Una matriz de paquetes adicionales cuyas características proporciona el software (o un paquete virtual como
cron
o
sh
). Los paquetes que proporcionan el mismo elemento se pueden instalar uno al lado del otro, a no ser que uno de ellos utilice una matriz
conflicts
.
Nota
Se debe mencionar la versión que proporciona el paquete (
pkgver
y potencialmente
pkgrel
), en caso de que los paquetes que hacen referencia al software lo requieran. Por ejemplo, un paquete modificado
qt
versión 3.3.8, llamado
qt-foobar
, debería utilizar
provides=('qt=3.3.8')
; omitir el número de versión haría que fallaran las dependencias que requieren una versión específica de
qt
. No añada
pkgname
a la matriz
provides
, ya que se hace automáticamente.
conflicts
Una matriz de paquetes que entran en conflicto o causan problemas con el paquete, si están instalados. Todos estos paquetes y los paquetes que proporcionen este elemento deberán eliminarse. Las propiedades de versión de los paquetes en conflicto también se pueden especificar en el mismo formato que la matriz
depends
.
Tenga en cuenta que los conflictos se comprueban con
pkgname
, así como con los nombres especificados en la matriz
provides
. Por lo tanto, si su paquete
provides
(proporciona) una función
foo
, especificar
foo
en la matriz
conflicts
causará un conflicto entre su paquete y todos los demás paquetes que contienen
foo
en su matriz
provides
(es decir, no necesita especificar todos esos nombres de paquetes en conflicto en su matriz
conflicts
). Tomemos un ejemplo concreto:
netbeans
proporciona implícitamente
netbeans
como el
pkgname
mismo
netbeans-cpp
AUR
[
enlace roto
: package not found]
proporciona
netbeans
y entra en conflicto con
netbeans
netbeans-php
AUR
[
enlace roto
: package not found]
proporciona
netbeans
y entra en conflicto con
netbeans
, pero no necesita entrar explícitamente en conflicto con
netbeans-cpp
AUR
[
enlace roto
: package not found]
ya que los paquetes que brindan la misma característica están implícitamente en conflicto.
Cuando los paquetes brindan la misma característica a través de la matriz
provides
, existe una diferencia entre añadir explícitamente el paquete alternativo a la matriz
conflicts
y no añadirlo. Si la matriz
conflicts
se declara explícitamente, los dos paquetes que brindan la misma función se considerarán
alternativos
; si falta la matriz
conflicts
, los dos paquetes que proporcionan la misma función se considerarán
cohabitantes posibles
. Los empaquetadores siempre deben ignorar el contenido de la variable
provides
al decidir si declarar una variable
conflicts
o no.
replaces
Una matriz de paquetes obsoletos que son reemplazados por el paquete, por ejemplo
wireshark-qt
utiliza
replaces=('wireshark')
. Al sincronizar,
pacman
reemplazará inmediatamente un paquete instalado al encontrar otro paquete con
replaces
coincidente en los repositorios. Si proporciona una versión alternativa de un paquete ya existente o lo sube en AUR, utilice las matrices
conflicts
y
provides
, que solo se evalúan cuando se instala el paquete en conflicto.
Otros
backup
Una matriz de archivos que pueden contener cambios realizados por el usuario y deben conservarse durante la actualización o eliminación de un paquete, destinados principalmente a archivos de configuración en
/etc
.
Los archivos en esta matriz deben utilizar rutas
relativas
sin la barra inclinada inicial (
/
) (por ejemplo,
etc/pacman.conf
, en lugar de
/etc/ pacman.conf
).
Al actualizar, las nuevas versiones se pueden guardar como
archivo
.pacnew
para evitar sobrescribir un archivo que ya existe y que el usuario modificó previamente. De manera similar, cuando se elimine el paquete, los archivos modificados por el usuario se conservarán como
archivo
.pacsave
a menos que el paquete se haya eliminado con la orden
pacman -Rn
.
Véase también
Archivos Pacnew y Pacsave
.
options
Esta matriz permite anular algunos de los comportamientos predeterminados de
makepkg
, definidos en
/etc/makepkg.conf
. Para establecer una opción, incluya el nombre en la matriz. Para desactivar una opción, coloca un
!
antes de ella.
La lista completa de las opciones disponibles se puede encontrar en
PKGBUILD(5)
.
install
El nombre del script
.install
que se incluirá en el paquete.
pacman
tiene la capacidad de almacenar y ejecutar un script específico de paquete cuando lo instala, elimina o actualiza. El script contiene las siguientes funciones que se ejecutan en diferentes momentos:
pre_install
— El script se ejecuta justo antes de que se extraigan los archivos. Se pasa un argumento: nueva versión del paquete.
post_install
— El script se ejecuta justo después de extraer los archivos. Se pasa un argumento: nueva versión del paquete.
pre_upgrade
— El script se ejecuta justo antes de que se extraigan los archivos. Se pasan dos argumentos en el siguiente orden: nueva versión del paquete, versión anterior del paquete.
post_upgrade
— El script se ejecuta justo después de extraer los archivos. Se pasan dos argumentos en el siguiente orden: nueva versión del paquete, versión anterior del paquete.
pre_remove
— El script se ejecuta justo antes de que se eliminen los archivos. Se pasa un argumento: versión anterior del paquete.
post_remove
— El script se ejecuta justo después de eliminar los archivos. Se pasa un argumento: versión anterior del paquete.
Cada función se ejecuta en un
chroot
dentro del directorio de instalación
pacman
. Véase
este hilo
.
Sugerencia
Se proporciona un prototipo
.install
en
/usr/share/pacman/proto.install
.
Los
Hooks de pacman
proporcionar una funcionalidad similar.
Nota
No termine el script con
exit
. Esto evitaría que las funciones contenidas se ejecuten.
changelog
El nombre del registro de cambios del paquete. Para ver los registros de cambios de los paquetes instalados (que tienen este archivo):
$ pacman -Qc
nombre_paquete
Fuentes
source
Una matriz de archivos necesarios para construir el paquete. Debe contener la ubicación de la fuente del software, que en la mayoría de los casos es una URL HTTP o FTP completa. Las variables configuradas previamente
pkgname
y
pkgver
se pueden utilizar de manera efectiva aquí; por ejemplo
source=("https://ejemplo.com/$pkgname-$pkgver.tar.gz")
.
Los archivos también se pueden proporcionar en el mismo directorio donde se encuentra
PKGBUILD
y sus nombres se pueden añadir a esta matriz. Antes de que comience el proceso de compilación actual, todos los archivos a los que se hace referencia en esta matriz se descargarán o comprobarán si existen, y
makepkg
no continuará si falta alguno.
Los archivos
.install
son reconocidos automáticamente por
makepkg
y no deben incluirse en la matriz
source
. Los archivos en la matriz
source
con extensiones
.sig
,
.sign
o
.asc
son reconocidos por
makepkg
como firmas PGP y se utilizarán automáticamente para verificar la integridad del archivo fuente correspondiente.
Advertencia
El nombre del archivo fuente descargado debe ser único porque el directorio
SRCDEST
puede ser el mismo para todos los paquetes. Por ejemplo, utilizar el número de versión del proyecto como nombre de archivo puede generar conflictos con otros proyectos con el mismo número de versión. En este caso, el nombre de archivo único alternativo que se utilizará se proporciona con la sintaxis
source=('
nombre_único_paquete
::
url_archivo
')
; por ejemplo
source=("$pkgname-$pkgver.tar.gz::https://github.com/programador/programa/archivo/v$pkgver.tar.gz")
.
Sugerencia
Se pueden añadir matrices adicionales específicos de la arquitectura añadiendo un guión bajo y el nombre de la arquitectura, por ejemplo
source_x86_64=()
. Debe haber una matriz de integridad correspondiente con sumas de verificación, por ejemplo
sha256sums_x86_64=()
.
Algunos servidores restringen la descarga filtrando la cadena
User-Agent
del cliente u otros tipos de restricciones, que se pueden eludir con
DLAGENTS
.
Puede utilizar la URL
file://
para apuntar a un directorio o un archivo en el sistema de archivos de su computadora. Por ejemplo, un repositorio Git local se puede especificar como
"$pkgname"::"git+file://
/ruta/al/repositorio
"
.
La compatibilidad con enlaces Magnet se puede añadir utilizando
transmission-dlagent
AUR
como
DLAGENT
y mediante el prefijo de URL
magnet://
en lugar del canónico
magnet:?
.
Véase
PKGBUILD(5) § USING VCS SOURCES
y
VCS package guidelines#VCS sources
para obtener detalles sobre las opciones específicas de VCS, como apuntar a una rama o un
commit
de Git específico.
noextract
Una matriz de archivos listados en
source
, que no deben ser extraídos de su formato de archivo por
makepkg
. Esto se puede utilizar con archivos que no pueden ser manejados por
/usr/bin/bsdtar
o aquellos que deben instalarse tal cual. Si se utiliza una herramienta alternativa para desarchivar (por ejemplo,
lrzip
), debe añadirse en la matriz
makedepends
y la primera línea de la función
prepare()
debe extraer el archivo fuente manualmente; por ejemplo:
prepare() {
  lrzip -d
fuente
.tar.lrz
}
Tenga en cuenta que mientras la matriz
source
acepta direcciones URL,
noextract
es
solo
la parte del nombre del archivo:
source=("http://foo.org/bar/foobar.tar.xz")
noextract=('foobar.tar.xz')
Para extraer
nada
, puede hacer algo como esto:
Si
source
contiene solo URLs sin formato sin nombres de archivo personalizados, elimine la matriz
source
antes de la última barra inclinada:
noextract=("${source[@]##*/}")
Si
source
contiene solo entradas con nombres de archivo personalizados, elimine la matriz
source
después del separador
::
(tomado de una versión anterior de
PKGBUILD de firefox-i18n
):
noextract=("${source[@]%%::*}")
validpgpkeys
Una serie de huellas dactilares (fingerprints) de PGP. Si se usa,
makepkg
solo aceptará firmas de las claves listadas aquí e ignorará los valores de confianza del conjunto de claves. Si el archivo fuente se firmó con una subclave,
makepkg
aún utilizará la clave principal para la comparación.
Solo se aceptan huellas dactilares completas. Deben estar en mayúsculas y no deben contener espacios en blanco.
Nota
Puede utilizar
gpg --list-keys --fingerprint
KEYID
para averiguar la huella digital de la clave adecuada.
Véase
makepkg (Español)#Verificación de firmas
para obtener más información.
Integridad
Estas variables son matrices cuyos elementos son cadenas de suma de verificación que se utilizarán para verificar la integridad de los archivos respectivos en la matriz
source
. También puede insertar
SKIP
para un archivo en particular, y su suma de verificación no se comprobará.
El tipo de suma de verificación y los valores siempre deben ser los proporcionados por
upstream
, como en los anuncios de lanzamiento. Cuando hay varios tipos disponibles, se prefiere la suma de verificación más fuerte:
b2
sobre
sha512
,
sha512
sobre
sha384
,
sha384
sobre
sha256
,
sha256
sobre
sha224
,
sha224
sobre
sha1
,
sha1
sobre
md5
, y
md5
sobre
ck
. Esto garantiza mejor la integridad de los archivos descargados, desde el anuncio de
upstream
hasta la creación del paquete.
Nota
Además, cuando
upstream
hace que las
firmas digitales
estén disponible, los archivos de firma deben añadirse a la matriz
source
y la huella digital de la clave PGP a la matriz
validpgpkeys
. Esto permite la autenticación de los archivos en el momento de la compilación.
Los valores para estas variables se pueden generar automáticamente mediante la opción
-g
/
--geninteg
de
makepkg
, luego se añaden comúnmente con
makepkg -g >> PKGBUILD
. La orden
updpkgsums(8)
de
pacman-contrib
puede actualizar las variables dondequiera que estén en
PKGBUILD
. Ambas herramientas utilizarán la variable que ya está configurada en
PKGBUILD
, o recurrirán a
md5sums
si no se configura ninguna.
Las comprobaciones de integridad de archivos que se utilizarán se pueden configurar con la opción
INTEGRITY_CHECK
en
/etc/makepkg.conf
. Véase
makepkg.conf(5)
.
Nota
Se pueden añadir matrices adicionales específicas de la arquitectura añadiendo un guión bajo y el nombre de la arquitectura, por ejemplo
sha256sums_x86_64=()
.
cksums
Una matriz de sumas de verificación
CRC32
(del estándar UNIX
cksum
) de los archivos listados en la matriz
source
.
md5sums
Una matriz de sumas de verificación
MD5
de 128 bits de los archivos listados en la matriz
source
.
sha1sums
Una matriz de sumas de verificación
SHA-1
de 160 bits de los archivos listados en la matriz
source
.
sha256sums
Una matriz de sumas de verificación
SHA-2
de 256 bits.
sha224sums, sha384sums, sha512sums
Una matriz de sumas de verificación SHA-2 de 224, 384 y 512 bits, respectivamente. Estas son alternativas menos comunes a
sha256sums
.
b2sums
Una matriz de sumas de verificación
BLAKE2
de 512 bits.
Véase también
La página de manual
PKGBUILD(5)
Ejemplo de archivo PKGBUILD