Daniel Mach de Red Hat sobre el inicio del desarrollo del gestor de paquetes DNF 5, en el cual se transferirá la lógica de DNF implementada en Python a la biblioteca libdnf, escrita en C++. Se prevé comenzar las pruebas de DNF 5 en junio durante el desarrollo de Fedora 33, y luego en octubre de 2020 añadirlo al repositorio Rawhide, y en febrero de 2021 reemplazar DNF 4 con él. El mantenimiento de la rama DNF 4 continuará, ya que se utiliza en Red Hat Enterprise Linux 8.
Se señala que el proyecto ha alcanzado un estado en el que es casi imposible continuar desarrollando el código sin romper la compatibilidad a nivel de API/ABI. Principalmente esto se debe a de relevancia de PackageKit y la imposibilidad de desarrollar libdnf sin cambiar la API de «libhif». Sin embargo, a pesar de la intención de cambiar la API, se mencionan como principales prioridades la conservación de la compatibilidad hacia atrás en la interfaz de línea de comandos y la API.
El soporte para la API de Python en DNF se mantendrá, pero la lógica de negocio escrita en Python se trasladará a la biblioteca libdnf (C++), lo que garantizará la identidad del funcionamiento del gestor de paquetes en la distribución. El desarrollo se centrará en la API de C++, y la API de Python se generará automáticamente como una envoltura basada en ella.
De manera similar, se formarán enlaces para Go, Perl y
Ruby. Después de estabilizar la API de C++, se preparará una API de C basada en ella, a la que se trasladará rpm-ostree. La API de Python se eliminará y se reemplazará por la API de Python.
La funcionalidad principal de DNF se conservará. Gracias a la existencia de un amplio conjunto de pruebas (alrededor de 1400 pruebas), se espera que la reestructuración de la API no afecte la interfaz de línea de comandos para los usuarios finales. Es posible que cambien ligeramente el análisis de argumentos y la salida, pero estos cambios estarán bien documentados. En una versión reducida, , utilizada en contenedores, se prevé implementar un subconjunto de las capacidades de DNF; no se considera lograr la paridad completa en funcionalidad.
En lugar de se creará un nuevo servicio DBus que proporcionará una interfaz para la gestión de paquetes y actualizaciones para aplicaciones gráficas. Este servicio se planea desarrollar desde cero, por lo que su creación puede llevar mucho tiempo. PackageKit no ha evolucionado en los últimos años y se encuentra en modo de mantenimiento desde 2014 debido a la pérdida de relevancia. Con la promoción de sistemas como Snaps y Flatpak, las distribuciones están perdiendo interés en PackageKit; por ejemplo, ya no se incluye en las compilaciones. . El nivel de abstracción para la gestión de paquetes es en gran parte proporcionado por los centros de gestión de aplicaciones de GNOME y KDE, que permiten instalar paquetes flatpak a nivel de usuarios individuales. Una API de sistema unificada para obtener la lista de paquetes instalados se vuelve menos útil que antes.
Fuente: opennet.ru
