En Fedora 39 planean migrar a DNF5, dejando de lado los componentes de Python

DNF5 debería mejorar la experiencia del usuario y proporcionar un mejor rendimiento

Ben Cotton, administrador de programas de Fedora en Red Hat, anunció hace poco en las listas de correo, su intención de migrar Fedora al administrador de paquetes DNF5 de manera predeterminada.

Se menciona que el cambio planeado será efectivo a partir del lanzamiento de Fedora 39, el cambio planea reemplazar los paquetes dnf, libdnf y dnf-cutomatic con el kit de herramientas DNF5 y la nueva biblioteca libdnf5.

Sobre el cambio, cabe mencionar que en su momento DNF reemplazó a Yum, que estaba escrito completamente en Python.

Para quienes desconocen de DNF, deben saber, que este 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. DNF es ahora la herramienta de administración de paquetes de software predeterminada en Fedora.

En DNF, las funciones de bajo nivel que demandan rendimiento se reescribieron y se trasladaron a bibliotecas C separadas hawkey, librepo, libsolv y libcomps, pero el marco y los componentes de alto nivel permanecieron en Python.

DNF5 proporcionará una mejora significativa en la experiencia del usuario y el rendimiento. El reemplazo es el segundo paso en la actualización de la pila de administración de software de Fedora. Sin el cambio, habrá múltiples herramientas de administración de software (DNF5, el antiguo Microdnf, PackageKit y DNF) basadas en diferentes bibliotecas (libdnf, libdnf5), que brindarán un comportamiento diferente y no compartirán un historial. También podemos esperar que DNF solo tenga un soporte limitado de upstream.

El proyecto DNF5 tiene como objetivo unificar las bibliotecas de bajo nivel existentes, reescribir en C ++ los componentes de administración de paquetes que quedan en Python y mover la funcionalidad básica a una biblioteca libdnf5 separada con la creación de un enlace alrededor de esta biblioteca para preservar la API de Python.

DNF5 todavía está en desarrollo y algunas de las funciones u opciones aún no están disponibles. Todavía tenemos que terminar la implementación de la Modularidad, el almacenamiento de datos internos relacionados con la Historia y el Estado del Sistema, y ​​también la documentación y las páginas man. DNF5 se puede probar desde el repositorio con compilaciones nocturnas ascendentes: Se suponía que d` no era modificable por el usuario y su formato no es suficiente (falta información sobre los paquetes instalados con perfiles instalados)

El uso de C++ en lugar de Python eliminará muchas dependencias, reducirá el tamaño del conjunto de herramientas y mejorará el rendimiento. Se logra un mayor rendimiento no solo mediante el uso de la compilación a código de máquina, sino también debido a la implementación mejorada de la tabla de transacciones, la optimización de la carga desde los repositorios y la reestructuración de la base de datos (se separan las bases de datos con el estado del sistema y el historial de operaciones).

DNF5 se ha desvinculado de PackageKit a favor de un nuevo proceso en segundo plano DNF Daemon que reemplaza la funcionalidad de PackageKit y proporciona una interfaz para administrar paquetes y actualizaciones en entornos gráficos.

El retrabajo también permitirá implementar algunas mejoras en la usabilidad del administrador de paquetes. Por ejemplo, el nuevo DNF tiene una indicación más visual del progreso de las operaciones; soporte agregado para usar paquetes RPM locales para transacciones; agregó la capacidad de mostrar en los informes sobre transacciones completadas información emitida por scripts integrados en paquetes (scriptlets); propuso un sistema de finalización de entrada más avanzado para bash.

Cabe mencionar que la propuesta aún no ha sido revisada por el FESCo (Comité Directivo de Ingeniería de Fedora), que es responsable de la parte técnica del desarrollo de la distribución de Fedora.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.