RPM Package Manager ( RPM ) (originalmente Red Hat Package Manager , ahora un 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 programa gestor de paquetes en sí. RPM fue pensado principalmente para distribuciones de Linux ; el formato de archivo es el formato de paquete base del estándar Linux Base ..rpm
Aunque fue creado para su uso en Red Hat Linux , RPM ahora se utiliza en muchas distribuciones Linux como PCLinuxOS , Fedora Linux , AlmaLinux , CentOS , openSUSE , OpenMandriva y Oracle Linux . También se ha 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 existen "RPM fuente" (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 (B)RPM 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] basándose en las experiencias de pms
, rpp
y pm
.
pm
Fue escrito por Rik Faith y Doug Hoffman en mayo de 1995 para Red Hat Software, su diseño e implementación fueron influenciados en gran medida por pms
, un sistema de administración de paquetes de Faith y Kevin Martin en el otoño de 1993 para la distribución Bogus Linux. pm
conserva el paradigma de " Fuentes prístinas + parches" de pms
, al tiempo que agrega características y elimina limitaciones arbitrarias presentes en la implementación. pm
proporciona un 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 consistencia y la capacidad de que estos procesos se automaticen y no sean interactivos. rpm utiliza Berkeley DB como base de datos de backend, aunque desde la versión 4.15 de 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 para ella por otras partes (por ejemplo, RPM Fusion para Fedora Linux). [13] Las dependencias circulares entre RPM mutuamente dependientes (el llamado " infierno de dependencias ") pueden ser problemáticas; [14] en tales casos, un solo comando de instalación debe especificar todos los paquetes relevantes.
Los RPM suelen recopilarse de forma centralizada en uno o más repositorios de Internet. Un sitio suele tener sus propios repositorios de RPM, que pueden actuar como espejos locales de dichos repositorios de Internet o ser colecciones de RPM útiles mantenidas localmente.
Existen varias interfaces para RPM que facilitan el proceso de obtención e instalación de RPM desde repositorios y ayudan a resolver sus dependencias. Entre ellas se incluyen:
rpmquery
, una utilidad de línea de comandos disponible en (por ejemplo) Red Hat Enterprise Linuxlibzypp
, para el sistema operativo SailfishDetrás de escena del administrador de paquetes se encuentra la base de datos RPM, almacenada en /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 (que utiliza 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 que es posible si se elimina el cliente RPM ), las bases de datos de índice se pueden volver a crear 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 solo 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 paquete nombre_archivo libgnomeuimm-2.0-2.0.0_3.i386.rpm
, el <name>
es libgnomeuimm
, el <version>
es 2.0
, el <release>
es 2.0.0_3
y el <architecture>
es 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 otros programas los utilicen. 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:
Los campos de etiqueta del paquete no necesitan 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 encabezados, etc. Esos paquetes tienen "-devel" adjunto 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 recuperar el 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. Se pueden compilar varios paquetes a partir de un único archivo de especificaciones de RPM, si se desea. Los paquetes RPM se crean a partir de archivos de especificaciones de 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. El código fuente correspondiente también se puede distribuir. 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 en sí.
Un paquete de software podría contener únicamente scripts independientes de la plataforma. En tal caso, el desarrollador podría proporcionar únicamente un SRPM, que sigue siendo un RPM instalable.
Esta es una versión especial de SRPM. Contiene el archivo "SPEC" y parches opcionales, 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, responsable del mantenimiento de RPM desde 1999, continuó con los esfuerzos de desarrollo junto con participantes de otras distribuciones. La versión 5 de RPM se publicó 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 otras 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}}
: CS1 maint: bot: estado de URL original desconocido ( enlace )()