PKGBUILD (Español)

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 .

Esta traducción de PKGBUILD fue revisada el 2022-11-02. Si existen cambios puede actualizarla o avisar al equipo de traducción.

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 (). El paquete resultante contiene archivos binarios e instrucciones de instalación, fácilmente instalables con pacman.

Las variables obligatorias son , , pkgrel y arch. 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.

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 .

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 , 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, debe coincidir con el nombre del tarball fuente del software: por ejemplo, si el software está en , utilice .

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 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").

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

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:

Véase 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 .

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 , pero otros proyectos pueden admitir otras arquitecturas. Por ejemplo, Arch Linux 32 brinda soporte para y pentium4 y Arch Linux ARM brinda soporte para (armv7 hardfloat) y (armv8 de 64 bits).

Hay dos tipos de valores que la matriz puede utilizar:

• 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).
• 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 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 (una dependencia del metapaquete ) 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 . Si no se incluye la licencia correspondiente, se deben hacer varias cosas:

1. Añadir custom a la matriz . Opcionalmente, puede reemplazar custom con . Una vez que una licencia se utiliza en dos o más paquetes en un repositorio oficial (incluido community), se convierte en parte del paquete .
2. Instalar la licencia en: , por ejemplo . Una buena forma de hacerlo es utilizando:
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 , debido a que incluyen avisos de derechos de autor . Por el bien de la matriz , se trata como una licencia común (, , , , 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 .
• Es posible que algunos paquetes no estén cubiertos por una sola licencia. En estos casos, se pueden realizar varias entradas en la matriz , por ejemplo .
• (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 . Sin embargo, se debe contactar a upstream sobre las condiciones bajo las cuales el software está (y no está) disponible.

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 , instala todos los paquetes que pertenecen a ese grupo.

Dependencias

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 solo son necesarias para ejecutar el software.

Las restricciones de versión se pueden especificar con operadores de comparación, por ejemplo ; 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 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 no se puede desinstalar ya que todos los sistemas necesitan alguna biblioteca C, o 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 .

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 . Los paquetes en la matriz se requieren implícitamente para construir el paquete, no deben duplicarse aquí.

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 . Estas dependencias solo se consideran cuando la función check() está presente y debe ser ejecutada por makepkg.

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. Si el software funciona en múltiples dependencias alternativas, todas ellas se pueden listar aquí, en lugar de la matriz .

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

provides

Una matriz de paquetes adicionales cuyas características proporciona el software (o un paquete virtual como 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

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 .

Tenga en cuenta que los conflictos se comprueban con , así como con los nombres especificados en la matriz . Por lo tanto, si su paquete (proporciona) una función , especificar en la matriz causará un conflicto entre su paquete y todos los demás paquetes que contienen en su matriz (es decir, no necesita especificar todos esos nombres de paquetes en conflicto en su matriz ). Tomemos un ejemplo concreto:

• proporciona implícitamente como el mismo
• netbeans-cpp^AUR proporciona y entra en conflicto con
• proporciona y entra en conflicto con , pero no necesita entrar explícitamente en conflicto con netbeans-cpp^AUR 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 , existe una diferencia entre añadir explícitamente el paquete alternativo a la matriz y no añadirlo. Si la matriz se declara explícitamente, los dos paquetes que brindan la misma función se considerarán alternativos; si falta la matriz , los dos paquetes que proporcionan la misma función se considerarán cohabitantes posibles. Los empaquetadores siempre deben ignorar el contenido de la variable al decidir si declarar una variable o no.

replaces

Una matriz de paquetes obsoletos que son reemplazados por el paquete, por ejemplo utiliza replaces=('wireshark'). Al sincronizar, pacman reemplazará inmediatamente un paquete instalado al encontrar otro paquete con coincidente en los repositorios. Si proporciona una versión alternativa de un paquete ya existente o lo sube en AUR, utilice las matrices y , 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 .

Los archivos en esta matriz deben utilizar rutas relativas sin la barra inclinada inicial () (por ejemplo, , en lugar de ).

Al actualizar, las nuevas versiones se pueden guardar como 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 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 . 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:

• — El script se ejecuta justo antes de que se extraigan los archivos. Se pasa un argumento: nueva versión del paquete.
• — El script se ejecuta justo después de extraer los archivos. Se pasa un argumento: nueva versión del paquete.
• — 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.
• — 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.
• — El script se ejecuta justo antes de que se eliminen los archivos. Se pasa un argumento: versión anterior del paquete.
• — 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.

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 y se pueden utilizar de manera efectiva aquí; por ejemplo .

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 . Los archivos en la matriz 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").

noextract

Una matriz de archivos listados en , 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 o aquellos que deben instalarse tal cual. Si se utiliza una herramienta alternativa para desarchivar (por ejemplo, ), debe añadirse en la matriz 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 acepta direcciones URL, 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 contiene solo URLs sin formato sin nombres de archivo personalizados, elimine la matriz antes de la última barra inclinada:

• Si contiene solo entradas con nombres de archivo personalizados, elimine la matriz después del separador :: (tomado de firefox-i18n's PKGBUILD):

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.

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 . También puede insertar 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: sobre , sobre , sobre sha256, sha256 sobre , sobre sha1, sha1 sobre , y sobre . Esto garantiza mejor la integridad de los archivos descargados, desde el anuncio de upstream hasta la creación del paquete.

Los valores para estas variables se pueden generar automáticamente mediante la opción / de makepkg, luego se añaden comúnmente con . La orden updpkgsums(8) de 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 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 . Véase .

cksums

Una matriz de sumas de verificación CRC32 (del estándar UNIX cksum) de los archivos listados en la matriz .

md5sums

Una matriz de sumas de verificación MD5 de 128 bits de los archivos listados en la matriz .

sha1sums

Una matriz de sumas de verificación SHA-1 de 160 bits de los archivos listados en la matriz .

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 .

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