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.

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:

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 firefox-i18n's PKGBUILD):

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