Red Hat Training

A Red Hat training course is available for RHEL 8

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 rpm utiliza 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 %buildroot. Esto es útil para investigar una construcción fallida si la salida de los registros no proporciona suficiente información.

RPMS

Los RPM binarios se crean aquí, en subdirectorios para diferentes arquitecturas, por ejemplo en los subdirectorios x86_64 y noarch.

FUENTES

Aquí, el empaquetador coloca los archivos de código fuente comprimidos y los parches. El comando rpmbuild los busca aquí.

SPECS

El empaquetador pone aquí los archivos SPEC.

SRPMS

Cuando se utiliza rpmbuild para construir un SRPM en lugar de un RPM binario, el SRPM resultante se crea aquí.

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.

Tabla 3.1. Los elementos utilizados en la sección Preamble del archivo RPM SPEC

Directiva SPECDefinición

Name

El nombre base del paquete, que debe coincidir con el nombre del archivo SPEC.

Version

El número de versión del software.

Release

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 Version del software.

Summary

Un breve resumen de una línea del paquete.

License

La licencia del software que se empaqueta.

URL

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.

Source0

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.

Patch

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.

BuildArch

Si el paquete no depende de la arquitectura, por ejemplo, si está escrito enteramente en un lenguaje de programación interpretado, configúrelo como BuildArch: noarch. Si no se establece, el paquete hereda automáticamente la Arquitectura de la máquina en la que se construye, por ejemplo x86_64.

BuildRequires

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 BuildRequires, cada una en su propia línea en el archivo SPEC.

Requires

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 Requires, cada una en su propia línea en el archivo SPEC.

ExcludeArch

Si un software no puede funcionar en una arquitectura de procesador específica, puede excluir esa arquitectura aquí.

Conflicts

Conflicts son inversas a Requires. Si hay un paquete que coincide con Conflicts, el paquete no puede ser instalado independientemente de si la etiqueta Conflict está en el paquete que ya ha sido instalado o en un paquete que va a ser instalado.

Obsoletes

Esta directiva altera la forma en que funcionan las actualizaciones dependiendo de si el comando rpm se utiliza directamente en la línea de comandos o la actualización es realizada por un solucionador de actualizaciones o dependencias. Cuando se utiliza en la línea de comandos, RPM elimina todos los paquetes que coinciden con los obsoletos de los paquetes que se están instalando. Cuando se utiliza un solucionador de actualizaciones o dependencias, los paquetes que coinciden con Obsoletes: se añaden como actualizaciones y sustituyen a los paquetes que coinciden.

Provides

Si se añade Provides a un paquete, se puede hacer referencia al paquete por otras dependencias que no sean su nombre.

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.

Tabla 3.2. Elementos utilizados en la sección del cuerpo del archivo RPM SPEC

Directiva SPECDefinición

%description

Una descripción completa del software empaquetado en el RPM. Esta descripción puede abarcar varias líneas y puede dividirse en párrafos.

%prep

Comando o serie de comandos para preparar el software a construir, por ejemplo, desempaquetando el archivo en Source0. Esta directiva puede contener un script de shell.

%build

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

%install

Comando o serie de comandos para copiar los artefactos de compilación deseados desde %builddir (donde se realiza la compilación) al directorio %buildroot (que contiene la estructura de directorios con los archivos a empaquetar). Esto normalmente significa copiar los archivos de ~/rpmbuild/BUILD a ~/rpmbuild/BUILDROOT y crear los directorios necesarios en ~/rpmbuild/BUILDROOT. Esto sólo se ejecuta cuando se crea un paquete, no cuando el usuario final instala el paquete. Véase Sección 3.2, “Trabajar con archivos SPEC” para más detalles.

%check

Comando o serie de comandos para probar el software. Esto incluye normalmente cosas como las pruebas unitarias.

%files

La lista de archivos que se instalarán en el sistema del usuario final.

%changelog

Un registro de los cambios que se han producido en el paquete entre diferentes construcciones de Version o Release.

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.

Nota

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.

Nota

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