Después de un año de desarrollo, se lanzó la versión 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ódigo del proyecto se distribuye bajo las licencias GPLv2 y LGPLv2.
Se espera que el próximo año se publique una rama importante de RPM 6, que incorporará un nuevo formato de archivo, permitiendo la creación de paquetes de más de 4 GB, superando así la limitación actual del formato cpio (este límite es importante ya que el paquete SRC de Chromium está cerca de él y tiene un tamaño de 3.7 GB). En esta nueva rama también se pretende permitir el uso del lenguaje C++ para el desarrollo de RPM. Esta importante versión estará vinculada al aniversario del proyecto; el 27 de noviembre de 2025 se cumplirán 30 años desde el primer commit en RPM. Se omitirán las versiones RPM 5.x para evitar conflictos con el proyecto RPM5, que no está directamente relacionado con el RPM de Red Hat, fue desarrollado por un equipo independiente y no se actualiza desde 2016.
Las mejoras más notables en RPM 4.20:
- Se ha incluido una nueva utilidad llamada rpm2archive, que sustituye a la utilidad rpm2cpio y facilitará la transición 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ólico a rpm2archive.
- Se ha propuesto un sistema de construcción declarativa, basado en el uso de la nueva directiva 'BuildSystem', a través de la cual se puede definir el sistema de construcción utilizado al crear el paquete. El código fuente se prepara, compila e instala automáticamente teniendo en cuenta el sistema de construcción especificado, sin necesidad de definir por separado en el archivo SPEC los scripts de preparación, construcción e instalación en los bloques '%prep', '%build' y '%install'. En RPM, los sistemas de construcción admitidos se definen en forma de colecciones de macros.
La idea principal es que el formato de configuración declarativa permitirá a los desarrolladores de distribuciones crear macros separadas para procesos de construcción típicos, evitando la necesidad de definir scripts repetitivos en cada paquete. Por ejemplo, en lugar de definir las secuencias de comandos configure y make para programas que utilizan Autotools, ahora solo es necesario especificar "BuildSystem: autotools" y omitir las secciones "%prep", "%build" y "%install". Actualmente, existen macros preparadas para Autotools y CMake. En caso de necesitar un comportamiento no estándar, los mantenedores de paquetes pueden conectar sus propias macros para redefinir diferentes etapas de la formación del paquete.
- Se ha añadido soporte para adjuntar secciones adicionales con comandos de preparación, construcción, instalación, configuración, limpieza y verificación, que complementan las secciones básicas %prep, %conf, %build, %install, %check y %clean. Para ejecutar un script adicional antes de ejecutar el código de la sección básica, se ha propuesto la opción "-p", y después de la sección básica, la opción "-a". Tales sustituciones pueden ser útiles para ajustes precisos del comportamiento al utilizar el modo de construcción declarativa mencionado anteriormente.
- Se permite incluir directivas y secciones en las partes dinámicamente generadas de los archivos SPEC, siempre que no afecten el proceso de construcción.
- Se ha añadido la macro %builddir y se ha implementado la gestión a través de RPM que permite vincular sus directorios de construcción a paquetes individuales.
- Se ha propuesto un nuevo protocolo "multi-file", que acelera significativamente la generación de dependencias.
- Se ha añadido la opción "—json" al comando rpm para la salida de resultados de consultas en formato JSON.
- Se ha añadido el complemento rpm-plugin-unshare, que proporciona aislamiento de scripts ejecutados en secciones de construcción, 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í como utilizar directorios privados separados /tmp y /home para protegerse en caso de un manejo inseguro de archivos temporales durante la construcción de paquetes.
- Se ha propuesto una API pública para el desarrollo de complementos, que mantendrá la compatibilidad entre versiones. Anteriormente, la API para complementos estaba diseñada solo para uso interno y podía cambiar de versión a versión.
- Se han añadido las opciones "—list" y "—delete" al comando rpmkeys.
- Se ha añadido soporte en el comando rpmsign para crear firmas digitales para paquetes utilizando claves ECDSA.
- Se ha mejorado el soporte para compilaciones repetibles. Se ha añadido el macro "%build_mtime_policy", que permite gestionar el contenido de las etiquetas añadidas durante la compilación con respecto al tiempo (a través del valor clamp_to_source_date_epoch se puede utilizar una etiqueta fija, y mediante clamp_to_buildtime se puede indicar la hora real de la compilación).
- En los archivos sysusers.d se permite añadir líneas para definir los miembros de un grupo.
- Se ha proporcionado soporte adecuado e independiente de las distribuciones para los archivos debuginfo.
- Se ha declarado obsoleto el uso de la sintaxis del macro %patchN (sin espacio antes de N), cuyo uso ahora provocará un error (se debe utilizar la sintaxis "%patch N" o "%patch -P N", donde N es el número del parche).
- Se ha eliminado el parser obsoleto de OpenPGP.
- Los generadores de dependencias para Perl y Python ABI se han trasladado a repositorios separados.
Fuente: opennet.ru
