Capítulo 3. Software de envasado
3.1. Paquetes RPM
Esta sección cubre los fundamentos del formato de embalaje RPM.
3.1.1. Qué es un RPM
Un paquete RPM es un archivo que contiene otros archivos y sus metadatos (información sobre los archivos que necesita el sistema).
En concreto, un paquete RPM consiste en el archivo cpio.
El archivo cpio contiene:
- Archivos
Cabecera del RPM (metadatos del paquete)
El gestor de paquetes
rpmutiliza estos metadatos para determinar las dependencias, dónde instalar los archivos y otra información.
Tipos de paquetes RPM
Hay dos tipos de paquetes RPM. Ambos tipos comparten el formato de archivo y las herramientas, pero tienen contenidos diferentes y sirven para fines distintos:
Fuente RPM (SRPM)
Un SRPM contiene el código fuente y un archivo SPEC, que describe cómo construir el código fuente en un RPM binario. Opcionalmente, también se incluyen los parches del código fuente.
RPM binario
Un RPM binario contiene los binarios construidos a partir de las fuentes y los parches.
3.1.2. Listado de utilidades de la herramienta de empaquetado RPM
Los siguientes procedimientos muestran cómo listar las utilidades proporcionadas por el paquete rpmdevtools.
Requisitos previos
Para poder utilizar las herramientas de empaquetado de RPM, es necesario instalar el paquete rpmdevtools, que proporciona varias utilidades para empaquetar RPMs.
# yum install rpmdevtools
Procedimiento
Lista de utilidades de la herramienta de empaquetado RPM:
$ rpm -ql rpmdevtools | grep bin
Información adicional
- Para más información sobre las utilidades anteriores, consulte sus páginas de manual o los diálogos de ayuda.
3.1.3. Configuración del espacio de trabajo de empaquetado RPM
Esta sección describe cómo configurar una distribución de directorios que es el espacio de trabajo de empaquetado de RPM utilizando la utilidad rpmdev-setuptree.
Requisitos previos
El paquete rpmdevtools debe estar instalado en su sistema:
# yum install rpmdevtools
Procedimiento
-
Ejecute la utilidad
rpmdev-setuptree:
$ rpmdev-setuptree $ tree ~/rpmbuild/ /home/user/rpmbuild/ |-- BUILD |-- RPMS |-- SOURCES |-- SPECS `-- SRPMS 5 directories, 0 files
Los directorios creados sirven para estos fines:
| Directorio | Propósito |
| CONSTRUIR |
Cuando se construyen los paquetes, se crean aquí varios directorios |
| RPMS |
Los RPM binarios se crean aquí, en subdirectorios para diferentes arquitecturas, por ejemplo en los subdirectorios |
| FUENTES |
Aquí, el empaquetador coloca los archivos de código fuente comprimidos y los parches. El comando |
| SPECS | El empaquetador pone aquí los archivos SPEC. |
| SRPMS |
Cuando se utiliza |
3.1.4. Qué es un archivo SPEC
Puede entender un archivo SPEC como una receta que la utilidad rpmbuild utiliza para construir un RPM. Un archivo SPEC proporciona la información necesaria al sistema de compilación definiendo instrucciones en una serie de secciones. Las secciones se definen en las partes Preamble y Body. La parte Preamble contiene una serie de metadatos que se utilizan en la parte Body. La parte Body representa la parte principal de las instrucciones.
3.1.4.1. Artículos del preámbulo
La siguiente tabla presenta algunas de las directivas que se utilizan frecuentemente en la sección Preamble del archivo RPM SPEC.
| Directiva SPEC | Definición |
|---|---|
|
| El nombre base del paquete, que debe coincidir con el nombre del archivo SPEC. |
|
| El número de versión del software. |
|
|
El número de veces que se ha publicado esta versión del software. Normalmente, se establece el valor inicial en 1%{?dist}, y se incrementa con cada nueva versión del paquete. Se restablece a 1 cuando se construye un nuevo |
|
| Un breve resumen de una línea del paquete. |
|
| La licencia del software que se empaqueta. |
|
| La URL completa para obtener más información sobre el programa. En la mayoría de los casos se trata del sitio web del proyecto de origen del software empaquetado. |
|
| Ruta o URL al archivo comprimido del código fuente upstream (sin parches, los parches se gestionan en otro lugar). Esto debería apuntar a un almacenamiento accesible y fiable del archivo, por ejemplo, la página de upstream y no el almacenamiento local del empaquetador. Si es necesario, se pueden añadir más directivas SourceX, incrementando el número cada vez, por ejemplo Source1, Source2, Source3, y así sucesivamente. |
|
| El nombre del primer parche que se aplicará al código fuente si es necesario. La directiva puede aplicarse de dos maneras: con o sin números al final de Patch. Si no se da ningún número, se asigna uno a la entrada internamente. También es posible dar los números explícitamente utilizando Parche0, Parche1, Parche2, Parche3, etc. Estos parches se pueden aplicar uno a uno utilizando la macro %patch0, %patch1, %patch2 y así sucesivamente. Las macros se aplican dentro de la directiva %prep en la sección Body del archivo RPM SPEC. Alternativamente, puede utilizar la macro topatch que aplica automáticamente todos los parches en el orden en que se dan en el archivo SPEC. |
|
|
Si el paquete no depende de la arquitectura, por ejemplo, si está escrito enteramente en un lenguaje de programación interpretado, configúrelo como |
|
|
Una lista separada por comas o espacios en blanco de los paquetes necesarios para construir el programa escrito en un lenguaje compilado. Puede haber varias entradas de |
|
|
Una lista separada por comas o espacios en blanco de los paquetes necesarios para que el software funcione una vez instalado. Puede haber varias entradas de |
|
| Si un software no puede funcionar en una arquitectura de procesador específica, puede excluir esa arquitectura aquí. |
|
|
|
|
|
Esta directiva altera la forma en que funcionan las actualizaciones dependiendo de si el comando |
|
|
Si se añade |
Las directivas Name, Version, y Release comprenden el nombre de archivo del paquete RPM. Los mantenedores de paquetes RPM y los administradores de sistemas suelen llamar a estas tres directivas N-V-R o NVR, porque los nombres de archivo de los paquetes RPM tienen el formato NAME-VERSION-RELEASE.
El siguiente ejemplo muestra cómo obtener la información de NVR para un paquete específico consultando el comando rpm.
Ejemplo 3.1. Consulta de rpm para proporcionar la información de NVR para el paquete bash
# rpm -q bash bash-4.4.19-7.el8.x86_64
Aquí, bash es el nombre del paquete, 4.4.19 es la versión, y 7.el8 es el lanzamiento. El último marcador es x86_64, que indica la arquitectura. A diferencia de NVR, el marcador de arquitectura no está bajo el control directo del empaquetador RPM, sino que está definido por el entorno de compilación rpmbuild. La excepción a esto es el paquete noarch, independiente de la arquitectura.
3.1.4.2. Artículos del cuerpo
Los elementos utilizados en el Body section del archivo RPM SPEC se enumeran en la siguiente tabla.
| Directiva SPEC | Definición |
|---|---|
|
| Una descripción completa del software empaquetado en el RPM. Esta descripción puede abarcar varias líneas y puede dividirse en párrafos. |
|
|
Comando o serie de comandos para preparar el software a construir, por ejemplo, desempaquetando el archivo en |
|
| Comando o serie de comandos para construir el software en código de máquina (para lenguajes compilados) o código de bytes (para algunos lenguajes interpretados). |
|
|
Comando o serie de comandos para copiar los artefactos de compilación deseados desde |
|
| Comando o serie de comandos para probar el software. Esto incluye normalmente cosas como las pruebas unitarias. |
|
| La lista de archivos que se instalarán en el sistema del usuario final. |
|
|
Un registro de los cambios que se han producido en el paquete entre diferentes construcciones de |
3.1.4.3. Artículos avanzados
El archivo SPEC también puede contener elementos avanzados, como Scriptlets o Triggers. Tienen efecto en diferentes puntos durante el proceso de instalación en el sistema del usuario final, no en el proceso de construcción.
3.1.5. BuildRoots
En el contexto del empaquetado RPM, buildroot es un entorno chroot. Esto significa que los artefactos de construcción se colocan aquí usando la misma jerarquía del sistema de archivos que la futura jerarquía en el sistema del usuario final, con buildroot actuando como el directorio raíz. La colocación de los artefactos de construcción debe cumplir con el estándar de la jerarquía del sistema de archivos del sistema del usuario final.
Los archivos de buildroot se colocan posteriormente en un archivo cpio, que se convierte en la parte principal del RPM. Cuando el RPM se instala en el sistema del usuario final, estos archivos se extraen en el directorio root, conservando la jerarquía correcta.
A partir de Red Hat Enterprise Linux 6, el programa rpmbuild tiene sus propios valores por defecto. Anular estos valores predeterminados conduce a varios problemas; por lo tanto, Red Hat no recomienda definir su propio valor de esta macro. Puede utilizar la macro %{buildroot} con los valores por defecto del directorio rpmbuild.
3.1.6. Macros RPM
Una macro de RPM es una sustitución de texto directa que puede ser asignada condicionalmente basada en la evaluación opcional de una sentencia cuando se utiliza cierta funcionalidad incorporada. Por lo tanto, RPM puede realizar sustituciones de texto por usted.
Un ejemplo de uso es hacer referencia al software empaquetado Version varias veces en un archivo SPEC. Defina Version sólo una vez en la macro %{version} y utilice esta macro en todo el archivo SPEC. Cada ocurrencia será automáticamente sustituida por Version que usted definió previamente.
Si ve una macro desconocida, puede evaluarla con el siguiente comando:
$ rpm --eval %{_MACRO}Evaluación de las macros %{_bindir} y %{_libexecdir}
$ rpm --eval %{_bindir}
/usr/bin
$ rpm --eval %{_libexecdir}
/usr/libexec
Una de las macros más utilizadas es la macro %{?dist}, que indica qué distribución se utiliza para la compilación (etiqueta de distribución).
# On a RHEL 8.x machine
$ rpm --eval %{?dist}
.el8