En Fedora planean reemplazar DNF con Microdnf

Hace poco los desarrolladores de Fedora dieron a conocer sus intenciones de migrar la distribución al nuevo administrador de paquetes llamado «Microdnf» en lugar del administrador de paquetes «DNF» que se usa actualmente.

El primer paso en el camino hacia la migración será una actualización importante de Microdnf, planificada para Fedora 38, que se acercará en funcionalidad a DNF e incluso lo superará en algunas áreas.

Se menciona que las intenciones de realizar dicha migración se debe a la diferencia clave entre Microdnf y DNF es el uso de C en lugar de Python para el desarrollo, lo que permite deshacerse de una gran cantidad de dependencias.

En un momento, DNF reemplazó a Yum, que estaba escrito completamente en Python, y en DNF, las funciones de bajo nivel que demandaban rendimiento se reescribieron y se trasladaron a bibliotecas separadas hawkey, librepo, libsolv y libcomps C, pero el marco y el alto nivel los componentes permanecieron en el lenguaje Python.

Microdnf se desarrolló originalmente como una versión simplificada de DNF para su uso en contenedores Docker que no requerían la instalación de Python. Ahora, los desarrolladores de Fedora planean llevar Microdnf al nivel de funcionalidad DNF y eventualmente reemplazar completamente DNF con Microdnf.

Una importante actualización de Microdnf es el primer paso en la evolución de la gestión de paquetes en Fedora. El nuevo microdnf tiene la ambición de proporcionar todas las funciones principales de DNF sin perder su huella mínima.

Microdnf se basa en la biblioteca libdnf5, desarrollada como parte del proyecto DNF 5. DNF 5 tiene como objetivo unificar las bibliotecas de bajo nivel existentes, reescribir en C ++ las operaciones de administración de paquetes restantes en Python y mover la funcionalidad básica a una biblioteca separada con la creación de un enlace alrededor de esta biblioteca para preservar la API de Python.

MICRODNF mejora significativamente la experiencia del usuario y en el futuro proporcionará todas las funciones importantes de DNF. También mantendrá todas las ventajas del MICRODNF original, como el tamaño mínimo requerido por los contenedores.

La nueva versión de Microdnf también utilizará el proceso en segundo plano DNF Daemon, reemplazando la funcionalidad PackageKit y brindando una interfaz para administrar paquetes y actualizaciones en entornos gráficos. A diferencia de PackageKit, DNF Daemon solo admitirá el formato RPM.

Está previsto que Microdnf, libdnf5 y DNF Daemon se envíen junto con el kit de herramientas DNF tradicional en la primera fase de implementación. Una vez que se complete el proyecto, el nuevo paquete reemplazará paquetes como dnf, python3-dnf, python3-hawkey, libdnf, dnfdragora y python3-dnfdaemon.

De las áreas en las que Microdnf es superior a DNF, se destaca: una indicación más visual del progreso de las operaciones; implementación mejorada de la tabla de transacciones; la capacidad de mostrar información en informes sobre transacciones completadas que se emite mediante scripts integrados en paquetes (scriptlets); soporte para usar paquetes RPM locales para transacciones; sistema de finalización de entrada más avanzado para bash; soporte para ejecutar el comando builddep sin instalar Python en el sistema.

Entre las desventajas de cambiar el administrador de paquetes de la distribución a Microdnf esta el cambio en la estructura de las bases de datos internas y el procesamiento de la base de datos separada de DNF, lo que no le permitirá ver transacciones con paquetes realizados en DNF en Microdnf y viceversa.

Los paquetes instalados previamente con DNF se tratarán como «instalados por el usuario del historial de dnf» después de migrar a Microdnf, y la desinstalación de un paquete instalado por otro administrador de paquetes no eliminará las dependencias no utilizadas asociadas con él. Además, Microdnf no tiene previsto mantener al 100% la compatibilidad DNF a nivel de comandos y opciones de línea de comandos.

Se observa que la nueva versión de Microdnf admitirá todas las funciones principales de DNF, pero al mismo tiempo conservará un alto rendimiento y compacidad.

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


El contenido del artículo se adhiere a nuestros principios de ética editorial. Para notificar un error pincha aquí.

Un comentario, deja el tuyo

Deja tu comentario

Tu dirección de correo electrónico no será publicada.

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.

  1.   khourt dijo

    Soy novato en la programación, y entusiasta en Linux. Nunca he usado Fedora pues siempre tengo un problema en la instalación y termino en Debían (y derivadas) u OpenSUSE. Pero creo entender la importancia en el mundo Linux, y lo relevante que lo que pasa en Fedora.
    Mi duda viene de la idea de sustituir Python por C/C++, ¿Porque implementar con un lenguaje de bajo nivel que viene siendo muy criticado por sus variantes y su estándar tan poco definido? Entiendo un poco el cambiar de un lenguaje interpretado a uno compilado, pero no entiendo el salto a un lenguaje por el que he visto que se busca usar menos en algunos ámbitos. ¿No sería mejor haber usado Rust o C# ?
    No crítico las desiciones de la gente de Fedora, si no buscar entender cómo avanza el mundo de la programación. Estoy aprendiendo Python y JS en web, y pensé en dar un brinco posterior a C/C++ por las bases, así que está nota me parece podría ayudarme con el enfoque.

    Muchas gracias! Y excelente trabajo como siempre a la gente de <•DesdeLinux

bool(true)