Jump to content

# PKGBUILD (Español)

From ArchWiki
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:

1. 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.
2. 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"

3. 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-cppAUR[enlace roto: package not found] proporciona `netbeans` y entra en conflicto con `netbeans`
- netbeans-phpAUR[enlace roto: package not found] proporciona `netbeans` y entra en conflicto con `netbeans`, pero no necesita entrar explícitamente en conflicto con netbeans-cppAUR[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-dlagentAUR 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

Category:

- Package development (Español)

Hidden category:

- Pages with broken package links

PKGBUILD (Español)
Add topic