Daniel Mach de Red Hat sobre el comienzo del desarrollo del administrador de paquetes DNF 5, en el que la lógica DNF implementada en Python se transferirá a la biblioteca libdnf escrita en C++. Está previsto que DNF 5 comience a probarse en junio durante el desarrollo de Fedora 33, después de lo cual se agregará al repositorio de Rawhide en octubre de 2020 y reemplazará a DNF 2021 en febrero de 4. El mantenimiento de la rama DNF 4 continuará como está. utilizado en Red Hat Enterprise Linux 8.
Cabe señalar que el proyecto ha llegado a un estado en el que es casi imposible continuar desarrollando el código sin romper la compatibilidad a nivel API/ABI. Esto se debe principalmente a la relevancia de PackageKit y la imposibilidad de desarrollar libdnf sin cambiar la API “libhif”. Al mismo tiempo, a pesar de la intención de cambiar la API, se dice que la principal prioridad es mantener la compatibilidad con versiones anteriores a nivel de la interfaz de línea de comandos y la API.
Se mantendrá la compatibilidad con la API de Python en DNF, pero la lógica empresarial escrita en Python se transferirá a la biblioteca libdnf (C++), lo que garantizará el funcionamiento idéntico del administrador de paquetes en la distribución. El desarrollo se centrará en la API de C++ y la API de Python se generará automáticamente en forma de un contenedor basado en ella.
Enlaces para Go, Perl y
Rubí. Una vez estabilizada la API de C++, se preparará una API de C a partir de ella, a la que se transferirá rpm-ostree. La API de Python será eliminada y reemplazada por API de Python.
Se conservará la funcionalidad principal de DNF. Debido al gran conjunto de pruebas (alrededor de 1400 pruebas), se espera que la revisión de la API no afecte la interfaz de línea de comandos para los usuarios finales. El análisis de argumentos y la salida pueden cambiar ligeramente, pero estos cambios estarán bien documentados. En una versión simplificada , utilizado en contenedores, se planea implementar un subconjunto de capacidades DNF; no se considera lograr la paridad total en la funcionalidad.
En lugar de Se creará un nuevo servicio DBus que proporciona una interfaz para administrar paquetes y actualizaciones para aplicaciones gráficas. Está previsto que este servicio se desarrolle desde cero, por lo que su creación puede llevar mucho tiempo. PackageKit no se ha desarrollado recientemente y ha estado en modo de mantenimiento desde 2014 debido a la pérdida de relevancia. Con el avance de los sistemas Snaps y Flatpak, las distribuciones están perdiendo interés en PackageKit, por ejemplo, ya no está disponible en compilaciones. . La capa de abstracción para la gestión de paquetes la proporcionan en gran medida los Centros de control de aplicaciones nativos de GNOME y KDE, que permiten la instalación de paquetes flatpak a nivel de usuario individual. La API del sistema unificado para obtener una lista de paquetes instalados no es tan útil como antes.
Fuente: opennet.ru