Fedora Linux 39 planea usar DNF5 por defecto para un mejor rendimiento
El Comité de Dirección e Ingeniería de Fedora (FESCo) anuncia que en Fedora 39 el equipo a cargo probablemente reemplazará DNF, libdnf y dnf-automatic con la nueva herramienta de empaquetado DNF5 y la biblioteca de soporte de libdnf5. DNF5 debería mejorar la experiencia del usuario y proporcionar un mejor rendimiento para administrar el software en Fedora Linux.
DNF es un administrador de paquetes de software que instala, actualiza y elimina paquetes en Fedora y es el sucesor de YUM (Yellow-Dog Updater Modified). DNF facilita el mantenimiento de paquetes al verificar automáticamente las dependencias y determinar las acciones necesarias para instalar paquetes. Este método elimina la necesidad de instalar o actualizar manualmente el paquete y sus dependencias mediante el comando rpm.
Sobre las nuevas funciones de DNF5 se destacan las siguientes:
- Gestor de paquetes completo sin necesidad de Python
- sistema más pequeño
- Más rápido
- Reemplaza DNF y Microdnf
- Comportamiento unificado en toda la pila de administración de software
- Los nuevos complementos de Libdnf5 (C++, Python) serán aplicables a DNF5 y Dnf5Daemon.
- Configuraciones compartidas
- DNF/YUM se ha desarrollado durante décadas con el impacto de múltiples estilos y convenciones de nomenclatura (opciones, configuración, opciones, comandos)
- Puede proporcionar una alternativa a PackageKit para RPM (un backend de PackageKit único) si está integrado en Desktop.
- Compatibilidad con el grupo Modularity y Comps
- Mejoras importantes en la base de código
- Separación del estado del sistema de la base de datos histórica y /etc/dnf/module.d
En dnf-4, la lista de paquetes instalados por el usuario y la lista de grupos instalados, así como la lista de paquetes instalados de estos grupos, se calculan como una agregación del historial de transacciones. En dnf5 se almacenará por separado, lo que tiene múltiples ventajas, entre las que destaca el hecho de que la base de datos de historial solo se utilizará con fines informativos y no definirá el estado del sistema (se corrompe ocasionalmente, etc.). Se supone que los datos almacenados en /etc/dnf/module.d no pueden ser editables por el usuario y su formato no es suficiente (falta información sobre los paquetes instalados con perfiles instalados).
DNF5 aún está en desarrollo y algunas funciones u opciones aún no están disponibles. Todavía queda trabajo por hacer en la implementación de la modularidad, el almacenamiento de datos internos relacionados con el historial y el estado del sistema, y la documentación y las páginas man. DNF5 se puede probar desde el repositorio con compilaciones nocturnas ascendentes.
DNF5 dejará obsoletos los complementos dnf, yum, dnf-automatic, yum-utils y DNF (núcleo y extras) python3-dnf y LIBDNF (libdnf, python3-hawkey) quedarán obsoletos con fedora-obsolete-packages, ademas de que proporcionará un enlace simbólico a /usr/bin/dnf, por lo que los usuarios verán el reemplazo como una actualización de DNF con cambios de sintaxis limitados pero documentados. DNF5 proporcionará algunos alias de comandos y opciones compatibles para mejorar la adopción de DNF5.
La propuesta de cambio resume las cosas de la siguiente manera:
- El nuevo DNF5 mejorará significativamente la experiencia y el rendimiento del usuario. Este reemplazo es el segundo paso en la actualización de la pila de administración de software de Fedora. Sin este cambio, habrá varias herramientas de administración de software (DNF5, el antiguo Microdnf, PackageKit y DNF) basadas en diferentes bibliotecas (libdnf, libdnf5), que ofrecerán un comportamiento diferente y no compartirán el historial. También es posible que DNF solo tenga un soporte de desarrollador limitado. El desarrollo de DNF5 se anunció en la lista Fedora-Devel en 2020.
- DNF5 elimina el código Python para lograr un sistema más pequeño, un rendimiento más rápido y para reemplazar las herramientas DNF y microdnf existentes. DNF5 también unifica el comportamiento de la pila de administración de software, presenta un nuevo demonio como alternativa a PackageKit para RPM y debería ser mucho más capaz. Se puede esperar un rendimiento más rápido en la búsqueda de repositorios, las operaciones de búsqueda, las consultas de RPM y el uso compartido de metadatos.
La propuesta de cambio aún debe ser aprobada por el Comité Directivo y de Ingeniería de Fedora, pero dada la participación de Red Hat en DNF(5), se puede suponer que será aprobada y, con suerte, que se completará a tiempo para el ciclo Fedora 39
Fuente: https://fedoraproject.org