Administrador de paquetes RPM

Los paquetes RPM suelen recopilarse de forma centralizada en uno o más repositorios de internet. Un sitio web a menudo tiene sus propios repositorios de RPM, que pueden funcionar como copias locales de dichos repositorios de internet o ser colecciones locales de paquetes RPM útiles.

Varias interfaces para RPM facilitan el proceso de obtención e instalación de paquetes RPM desde repositorios y ayudan a resolver sus dependencias. Estas incluyen:

• yum se utiliza en Fedora Linux , CentOS 5 y versiones posteriores, Red Hat Enterprise Linux 5 y versiones posteriores, Scientific Linux , Yellow Dog Linux y Oracle Linux.
• DNF , introducido en Fedora Linux 18 (predeterminado desde la versión 22 ), Red Hat Enterprise Linux 8, AlmaLinux 8 y CentOS Linux 8.
• up2date se utiliza en Red Hat Enterprise Linux , CentOS 3 y 4, y Oracle Linux.
• Zypper se utiliza en Mer (y por lo tanto en Sailfish OS), MeeGo , ^{[ 16 ]} openSUSE y SUSE Linux Enterprise.
• urpmi se utiliza en Mandriva Linux , ROSA Linux y Mageia.
• apt-rpm , una adaptación de la herramienta de empaquetado avanzado (APT) de Debian utilizada en Ark Linux, ^{[ 17 ]} PCLinuxOS y ALT Linux
• Smart Package Manager , utilizado en Unity Linux, está disponible para muchas distribuciones, incluyendo Fedora Linux .
• rpmquery, una utilidad de línea de comandos disponible en (por ejemplo) Red Hat Enterprise Linux
• libzypp, para Sailfish OS

Detrás del gestor de paquetes funciona la base de datos RPM, almacenada en /var/lib/rpm. Utiliza Berkeley DB como backend. Consta de una única base de datos ( Packages) que contiene toda la metainformación de los RPM instalados. Se crean varias bases de datos para fines de indexación, replicando datos para acelerar las consultas. La base de datos se utiliza para realizar un seguimiento de todos los archivos que se modifican y crean cuando un usuario (mediante RPM) instala un paquete, lo que permite al usuario (a través de RPM) revertir los cambios y eliminar el paquete posteriormente. Si la base de datos se corrompe (lo cual es posible si se cierra el cliente RPM ), las bases de datos de índice se pueden recrear con el rpm --rebuilddbcomando. ^{[ 18 ]}

Un paquete RPM se entrega en un único archivo, normalmente con un nombre de archivo en el formato:

<name>-<version>-<release>.src.rpmpara paquetes fuente, o

<name>-<version>-<release>.<architecture>.rpmpara binarios.

Por ejemplo, en el archivo del paquete libgnomeuimm-2.0-2.0.0_3.i386.rpm, el <name>es libgnomeuimm, el <version>es 2.0, el <release>es 2.0.0_3y el <architecture>es i386. El paquete fuente asociado se llamaríalibgnomeuimm-2.0-2.0.0_3.src.rpm

Los paquetes RPM con esta noarch.rpmextensión no dependen de una arquitectura de CPU específica. Por ejemplo, estos paquetes RPM pueden contener gráficos y texto para que los utilicen otros programas. También pueden contener scripts de shell o programas escritos en otros lenguajes de programación interpretados, como Python .

El contenido del RPM también incluye una etiqueta de paquete , que contiene la siguiente información:

• nombre del software
• Versión del software (la versión tomada de la fuente original del software)
• Versión del paquete (número de veces que el paquete se ha recompilado utilizando la misma versión del software). Este campo también se usa a menudo para indicar la distribución específica a la que está destinado el paquete, añadiendo cadenas como "mdv" (anteriormente, "mdk") ( Mandriva Linux ), "mga" ( Mageia ), "fc4" ( Fedora Core 4), "rh9" ( Red Hat Linux 9), "suse100" ( SUSE Linux 10.0), etc.
• arquitectura para la que se creó el paquete (i386, i686, x86_64, ppc, etc.)

Los campos de la etiqueta del paquete no tienen por qué coincidir con el nombre del archivo.

Las bibliotecas se distribuyen en dos paquetes separados para cada versión. Uno contiene el código precompilado para su uso en tiempo de ejecución, mientras que el segundo contiene los archivos de desarrollo relacionados, como los archivos de cabecera, etc. Estos paquetes tienen la extensión "-devel" añadida al nombre. El administrador del sistema debe asegurarse de que las versiones de los paquetes binarios y de desarrollo coincidan.

El formato es binario y consta de cuatro secciones: ^{[ 7 ]}

• El encabezado, que identifica el archivo como un archivo RPM y contiene algunos encabezados obsoletos.
• La firma, que puede utilizarse para garantizar la integridad y/o autenticidad.
• El encabezado, que contiene metadatos como el nombre del paquete, la versión, la arquitectura, la lista de archivos, etc.
• Un archivo comprimido (la carga útil ), que generalmente está en formato cpio , comprimido con gzip . La rpm2cpioherramienta permite recuperar el archivo cpio sin necesidad de instalar el paquete RPM. ^{[ 19 ]}
  • Linux Standard Base requiere el uso de gzip, pero los paquetes de Fedora 30 están comprimidos con xz y los paquetes de Fedora 31 podrían estar comprimidos con zstd . ^{[ 20 ]} Las versiones recientes de RPM también pueden usar compresión bzip2 , lzip , ^{[ 21 ]} o lzma .
  • El formato RPM 5.0 admite el uso de xar para el archivado.

La "receta" para crear un paquete RPM es un archivo de especificación. Estos archivos terminan con la extensión ".spec" y contienen el nombre del paquete, la versión, el número de revisión RPM, los pasos para compilar, instalar y limpiar el paquete, y un registro de cambios. Si se desea, se pueden crear varios paquetes a partir de un único archivo de especificación RPM. Los paquetes RPM se crean a partir de archivos de especificación RPM mediante la herramienta rpmbuild.

Los archivos de especificación suelen distribuirse dentro de los archivos SRPM, que contienen el archivo de especificación empaquetado junto con el código fuente.

Un RPM típico es un software precompilado listo para su instalación directa. También se puede distribuir el código fuente correspondiente. Esto se realiza mediante un SRPM, que incluye el archivo "SPEC" que describe el software y su proceso de compilación. El SRPM también permite al usuario compilar y, posiblemente, modificar el código.

Un paquete de software podría contener únicamente scripts independientes de la plataforma. En tal caso, el desarrollador podría proporcionar solo un SRPM, que sigue siendo un RPM instalable.

Esta es una versión especial de SRPM. Contiene el archivo "SPEC" y, opcionalmente, parches, pero no incluye el código fuente (generalmente debido a la licencia). ^{[ 22 ]}

La primera revisión importante del código de la comunidad rpm.org se produjo en julio de 2007; la versión 4.8 se lanzó en enero de 2010, la versión 4.9 en marzo de 2011, la 4.10 en mayo de 2012, la 4.11 en enero de 2013, la 4.12 en septiembre de 2014 y la 4.13 en julio de 2015.

Esta versión es utilizada por distribuciones como Fedora Linux , Red Hat Enterprise Linux y derivados , openSUSE , SUSE Linux Enterprise , Unity Linux , Mageia , ^{[ 23 ]} OpenEmbedded , Tizen y OpenMandriva Lx (anteriormente Mandriva ).

Jeff Johnson, responsable del mantenimiento de RPM desde 1999, continuó los esfuerzos de desarrollo junto con participantes de varias otras distribuciones. La versión 5 de RPM se lanzó en mayo de 2007.

Esta versión fue utilizada por distribuciones como Wind River Linux (hasta Wind River Linux 10), Rosa Linux y OpenMandriva Lx (anteriormente Mandriva Linux , que cambió a rpm5 en 2011 ^{[ 24 ]} ) y también por el proyecto OpenPKG , que proporciona paquetes para otras plataformas UNIX comunes.

OpenMandriva Lx ha vuelto a utilizar rpm.org ^{[ 25 ]} para la versión 4.0.

OpenEmbedded , el último usuario importante de RPM5, volvió a rpm.org debido a problemas en RPM5. ^{[ 26 ] [ 27 ]}