RPM Package Manager ( RPM ) (originalmente Red Hat Package Manager , ahora acrónimo recursivo ) es un sistema de gestión de paquetes gratuito y de código abierto . [6] El nombre RPM se refiere al formato de archivo y al propio programa administrador de paquetes. RPM estaba destinado principalmente a distribuciones de Linux ; el formato de archivo es el formato de paquete básico de Linux Standard Base ..rpm
Aunque fue creado para su uso en Red Hat Linux , RPM ahora se usa en muchas distribuciones de Linux como PCLinuxOS , Fedora , AlmaLinux , CentOS , openSUSE , OpenMandriva y Oracle Linux . También ha sido portado a algunos otros sistemas operativos , como Novell NetWare (a partir de la versión 6.5 SP3), AIX de IBM (a partir de la versión 4), [7] IBM i , [8] y ArcaOS . [9]
Un paquete RPM puede contener un conjunto arbitrario de archivos. La mayoría de los archivos RPM son "RPM binarios" (o BRPM) que contienen la versión compilada de algún software. También hay "RPM de origen" (o SRPM) que contienen el código fuente utilizado para crear un paquete binario. Estos tienen una etiqueta apropiada en el encabezado del archivo que los distingue de los RPM (B) normales, lo que hace que se extraigan a /usr/src durante la instalación. Los SRPM suelen llevar la extensión de archivo ".src.rpm" (.spm en sistemas de archivos limitados a 3 caracteres de extensión, por ejemplo, el antiguo DOS FAT ).
RPM fue escrito originalmente en 1997 por Erik Troan y Marc Ewing , [1] basado en pms
, rpp
y pm
experiencias.
pm
fue escrito por Rik Faith y Doug Hoffman en mayo de 1995 para Red Hat Software, su diseño e implementaciones estuvieron muy influenciados por pms
, un sistema de gestión de paquetes creado por Faith y Kevin Martin en el otoño de 1993 para Bogus Linux Distribution. pm
conserva el paradigma de " Fuentes Pristinepms
+ parches" , al tiempo que agrega características y elimina limitaciones arbitrarias presentes en la implementación. pm
proporciona soporte de base de datos muy mejorado para rastrear y verificar paquetes instalados. [4] [10] [11]
Para un administrador de sistemas que realiza la instalación y el mantenimiento de software, el uso de la gestión de paquetes en lugar de la creación manual tiene ventajas como la simplicidad, la coherencia y la capacidad de que estos procesos sean automatizados y no interactivos. rpm usa Berkeley DB como base de datos backend, aunque desde 4.15 en 2019, admite la creación de paquetes rpm sin Berkeley DB ( –disable-bdb
). [12]
Las características de RPM incluyen:
.tar.gz
, .tar.bz2
) se incluyen en los SRPM, lo que facilita la verificaciónLos paquetes pueden provenir de una distribución particular (por ejemplo, Red Hat Enterprise Linux ) o ser creados por otras partes (por ejemplo, RPM Fusion para Fedora Linux). [13] Las dependencias circulares entre RPM mutuamente dependientes (el llamado " infierno de dependencia ") pueden ser problemáticas; [14] en tales casos, un único comando de instalación debe especificar todos los paquetes relevantes.
Los RPM suelen recopilarse de forma centralizada en uno o más repositorios en Internet. Un sitio a menudo tiene sus propios repositorios RPM que pueden actuar como espejos locales de dichos repositorios de Internet o ser colecciones de RPM útiles mantenidas localmente.
Varias interfaces para RPM facilitan el proceso de obtención e instalación de RPM desde repositorios y ayudan a resolver sus dependencias. Éstas incluyen:
rpmquery
, una utilidad de línea de comandos disponible en (por ejemplo) Red Hat Enterprise Linuxlibzypp
, para el sistema operativo SailfishTrabajando detrás de escena del administrador de paquetes está la base de datos RPM, almacenada en formato /var/lib/rpm
. Utiliza Berkeley DB como back-end. Consiste en una única base de datos ( Packages
) que contiene toda la metainformación de los RPM instalados. Se crean múltiples bases de datos con 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 (usando RPM) instala un paquete, lo que permite al usuario (a través de RPM) revertir los cambios y eliminar el paquete más tarde. Si la base de datos se corrompe (lo cual es posible si se elimina el cliente RPM ), las bases de datos indexadas se pueden recrear con el rpm --rebuilddb
comando. [17]
Si bien el formato RPM es el mismo en las diferentes distribuciones de Linux , las convenciones y pautas detalladas pueden variar entre ellas.
Un RPM se entrega en un único archivo, normalmente con un nombre de archivo en el formato:
<name>-<version>-<release>.src.rpm
para paquetes fuente, o<name>-<version>-<release>.<architecture>.rpm
para binarios.Por ejemplo, en el nombre de archivo del paquete libgnomeuimm-2.0-2.0.0_3.i386.rpm
, <name>
is libgnomeuimm
, <version>
is 2.0
, <release>
is 2.0.0_3
, is y <architecture>
is i386
. El paquete fuente asociado se llamaríalibgnomeuimm-2.0-2.0.0_3.src.rpm
Los RPM con la noarch.rpm
extensión no dependen de una arquitectura de CPU en particular. Por ejemplo, estos 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:
No es necesario que los campos de la etiqueta del paquete coincidan con el nombre del archivo.
Las bibliotecas se distribuyen en dos paquetes separados para cada versión. Uno contiene el código precompilado para usar en tiempo de ejecución, mientras que el segundo contiene los archivos de desarrollo relacionados, como encabezados, etc. Esos paquetes tienen "-devel" agregado a su campo de 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: [6]
rpm2cpio
herramienta permite la recuperación del archivo cpio sin necesidad de instalar el paquete RPM. [18]La "Receta" para crear un paquete RPM es un archivo de especificaciones. Los archivos de especificaciones terminan con el sufijo ".spec" y contienen el nombre del paquete, la versión, el número de revisión de RPM, los pasos para compilar, instalar y limpiar un paquete y un registro de cambios. Si se desea, se pueden crear varios paquetes a partir de un único archivo de especificaciones RPM. Los paquetes RPM se crean a partir de archivos de especificaciones RPM utilizando la herramienta rpmbuild.
Los archivos de especificaciones generalmente se distribuyen dentro de archivos SRPM, que contienen el archivo de especificaciones 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 hace en un SRPM, que también incluye el archivo "SPEC" que describe el software y cómo está construido. El SRPM también permite al usuario compilar y quizás modificar el código mismo.
Un paquete de software sólo puede contener scripts independientes de la plataforma. En tal caso, el desarrollador podría proporcionar sólo 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 fuentes (normalmente debido a la licencia). [21]
En junio de 2010 [actualizar], hay dos versiones de RPM en desarrollo: una dirigida por el Proyecto Fedora y Red Hat, y la otra por un grupo separado dirigido por un anterior mantenedor de RPM, un ex empleado de Red Hat.
La primera revisión importante del código de la comunidad rpm.org fue 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 , [22] OpenEmbedded , Tizen y OpenMandriva Lx (anteriormente Mandriva ).
Jeff Johnson, mantenedor 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 (antiguo Mandriva Linux que cambió a rpm5 en 2011 [23] ) y también por el proyecto OpenPKG que proporciona paquetes para otros plataformas UNIX comunes.
OpenMandriva Lx ha vuelto a rpm.org [24] para la versión 4.0. [ necesita actualización ]
OpenEmbedded , el último usuario importante de RPM5, volvió a rpm.org debido a problemas en RPM5. [25] [26]
{{cite web}}
: Mantenimiento CS1: bot: estado de la URL original desconocido ( enlace )()