{"id":120153,"date":"2024-10-12T13:09:06","date_gmt":"2024-10-12T11:09:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-paketnogo-menedzhera-rpm-4-20-i-nachalo-razrabotki-rpm-6"},"modified":"2024-10-12T13:09:06","modified_gmt":"2024-10-12T11:09:06","slug":"vypusk-paketnogo-menedzhera-rpm-4-20-i-nachalo-razrabotki-rpm-6","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/vypusk-paketnogo-menedzhera-rpm-4-20-i-nachalo-razrabotki-rpm-6","title":{"rendered":"Lanzamiento del gestor de paquetes RPM 4.20 y comienzo del desarrollo de RPM 6","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Despu\u00e9s de un a\u00f1o de desarrollo, se lanz\u00f3 la versi\u00f3n 4.20.0 del gestor de paquetes RPM. El proyecto RPM4 es desarrollado por Red Hat y se utiliza en distribuciones como RHEL, Fedora, SUSE, openSUSE, ALT Linux, OpenMandriva, Mageia, PCLinuxOS y Tizen. El c\u00f3digo del proyecto se distribuye bajo las licencias GPLv2 y LGPLv2. <\/p>\n
El pr\u00f3ximo a\u00f1o se espera la publicaci\u00f3n de una rama significativa de RPM 6, que utilizar\u00e1 un nuevo formato de archivo que, a diferencia del formato cpio actualmente utilizado, permitir\u00e1 crear paquetes de m\u00e1s de 4 GB (la superaci\u00f3n de este l\u00edmite es importante ya que el paquete SRC de Chromium est\u00e1 cerca del l\u00edmite y tiene un tama\u00f1o de 3.7 GB). En esta nueva rama tambi\u00e9n se permitir\u00e1 el uso del lenguaje C++ para el desarrollo de RPM. Esta nueva versi\u00f3n significativa estar\u00e1 marcada por el aniversario del proyecto: el 27 de noviembre de 2025 se cumplir\u00e1n 30 a\u00f1os desde el primer commit en RPM. Las versiones de RPM 5.x se omitir\u00e1n para evitar confusiones con el proyecto RPM5, que no est\u00e1 relacionado con RPM de Red Hat, y que ha sido desarrollado por un equipo independiente de programadores y no se actualiza desde 2016. <\/p>\n
Las mejoras m\u00e1s notables en RPM 4.20: <\/p>\n
\n
Se ha incluido una nueva utilidad llamada rpm2archive, que sustituye a la utilidad rpm2cpio y facilitar\u00e1 la transici\u00f3n al nuevo formato de paquetes que no utiliza cpio. A diferencia de rpm2cpio, la nueva utilidad convierte el archivo RPM no en un archivo cpio, sino en un archivo en formato tar, comprimido utilizando gzip. La antigua utilidad rpm2cpio ha sido reemplazada por un enlace simb\u00f3lico a rpm2archive.\n
Se ha propuesto un sistema de construcci\u00f3n declarativo, basado en el uso de la nueva directiva \"BuildSystem\", a trav\u00e9s de la cual puede definirse el sistema de construcci\u00f3n que se utilizar\u00e1 para la creaci\u00f3n del paquete. El c\u00f3digo fuente se prepara, compila e instala autom\u00e1ticamente teniendo en cuenta el sistema de construcci\u00f3n especificado, sin necesidad de definir por separado en el archivo SPEC los scripts de preparaci\u00f3n, construcci\u00f3n e instalaci\u00f3n en los bloques \"%prep\", \"%build\" y \"%install\". En RPM, los sistemas de construcci\u00f3n admitidos se definen en forma de colecciones de macros.\n
La idea principal es que el formato de configuraci\u00f3n declarativa permitir\u00e1 a los desarrolladores de distribuciones crear macros separadas para procesos de construcci\u00f3n t\u00edpicos, evitando la necesidad de definir escenarios repetidos en cada paquete. Por ejemplo, en lugar de definir las secuencias de comandos configure y make para los programas que utilizan Autotools, ahora es suficiente especificar \"BuildSystem: autotools\" y prescindir de las secciones \"%prep\", \"%build\" y \"%install\". Actualmente se han preparado tales macros para Autotools y CMake. Si es necesario implementar un comportamiento no est\u00e1ndar, se ofrece a los que acompa\u00f1an los paquetes la posibilidad de conectar sus propias macros para redefinir diferentes etapas de la creaci\u00f3n del paquete. <\/p>\n
Se ha a\u00f1adido soporte para adjuntar secciones adicionales con comandos de preparaci\u00f3n, construcci\u00f3n, instalaci\u00f3n, configuraci\u00f3n, limpieza y verificaci\u00f3n, que complementan las secciones b\u00e1sicas %prep, %conf, %build, %install, %check y %clean. Para ejecutar un script adicional antes de ejecutar el c\u00f3digo de la secci\u00f3n base, se ha propuesto la opci\u00f3n \u00ab-p\u00bb, y despu\u00e9s de la secci\u00f3n base \u2014 la opci\u00f3n \u00ab-a\u00bb. Estas sustituciones pueden resultar \u00fatiles para ajustar el comportamiento al utilizar el modo de construcci\u00f3n declarativa descrito anteriormente.\n
Se permite incluir directivas y secciones en las partes din\u00e1micamente generadas de los archivos SPEC, siempre que no afecten el proceso de construcci\u00f3n.\n
Se ha a\u00f1adido la macro %builddir y se ha implementado la gesti\u00f3n a trav\u00e9s de RPM que permite vincular sus directorios de construcci\u00f3n a paquetes individuales.\n
Se ha propuesto un nuevo protocolo \u00abmulti-file\u00bb que acelera significativamente la generaci\u00f3n de dependencias.\n
Se ha a\u00f1adido la opci\u00f3n \u00ab--json\u00bb al comando rpm para mostrar los resultados de las consultas en formato JSON.\n
Se ha a\u00f1adido el complemento rpm-plugin-unshare, que proporciona aislamiento de scripts ejecutados en secciones de construcci\u00f3n, utilizando espacios de nombres en Linux. Por ejemplo, el complemento permite prohibir el acceso a la red y restringir el acceso al sistema de archivos, as\u00ed como utilizar directorios privados separados \/tmp y \/home para protegerse en caso de un manejo inseguro de archivos temporales durante la construcci\u00f3n de paquetes.\n
Se ha propuesto una API p\u00fablica para el desarrollo de complementos, que mantendr\u00e1 la compatibilidad entre versiones. Anteriormente, la API para complementos estaba dise\u00f1ada solo para uso interno y pod\u00eda cambiar de versi\u00f3n a versi\u00f3n.\n
Se han a\u00f1adido las opciones \u00ab--list\u00bb y \u00ab--delete\u00bb al comando rpmkeys.\n
Se ha a\u00f1adido soporte en el comando rpmsign para crear firmas digitales para paquetes utilizando claves ECDSA.\n
Se ha mejorado el soporte para construcciones repetibles. Se ha a\u00f1adido el macro \u00ab%build_mtime_policy\u00bb, que permite gestionar el contenido de las etiquetas a\u00f1adidas durante la construcci\u00f3n con respecto al tiempo (con el valor clamp_to_source_date_epoch se puede utilizar una etiqueta fija, mientras que con clamp_to_buildtime se puede especificar el tiempo real de construcci\u00f3n).\n
En los archivos sysusers.d se permite a\u00f1adir l\u00edneas para definir los miembros de un grupo.\n
Se ha proporcionado soporte adecuado e independiente de las distribuciones para los archivos debuginfo.\n
Se ha declarado obsoleto el uso de la sintaxis de macros %patchN (sin espacio antes de N), ya que su uso ahora generar\u00e1 un error (debe utilizarse la sintaxis \u00ab%patch N\u00bb o \u00ab%patch -P N\u00bb, donde N es el n\u00famero del parche).\n
Se ha eliminado el parser obsoleto de OpenPGP.\n
Los generadores de dependencias para Perl y Python ABI se han trasladado a repositorios separados. <\/ul>\n