Fa poc els desenvolupadors de Fedora van donar a conèixer les seves intencions de migrar la distribució al nou administrador de paquets anomenat «Microdnf» en lloc de l'administrador de paquets DNF que es fa servir actualment.
El primer pas en el camí cap a la migració serà una actualització important de Microdnf, planificada per a Fedora 38, que s'aproparà en funcionalitat a DNF i fins i tot el superarà en algunes àrees.
S'esmenta que les intencions de realitzar aquesta migració es deu a la diferència clau entre Microdnf i DNF és lús de C en lloc de Python per al desenvolupament, el que permet desfer-se duna gran quantitat de dependències.
En un moment, DNF va reemplaçar a Yum, que estava escrit completament a Python, ia DNF, les funcions de baix nivell que demanaven rendiment es van reescriure i es van traslladar a biblioteques separades hawkey, librepo, libsolv i libcomps C, però el marc i el alt nivell els components van romandre en el llenguatge Python.
Microdnf es va desenvolupar originalment com una versió simplificada de DNF per al seu ús en contenidors Docker que no requerien la instal·lació de Python. Ara, els desenvolupadors de Fedora planegen portar Microdnf al nivell de funcionalitat DNF i eventualment reemplaçar completament DNF amb Microdnf.
Una important actualització de Microdnf és el primer pas en l'evolució de la gestió de paquets a Fedora. El microdnf nou té l'ambició de proporcionar totes les funcions principals de DNF sense perdre la seva petjada mínima.
Microdnf es basa a la biblioteca libdnf5, desenvolupada com a part del projecte DNF 5. DNF 5 té com a objectiu unificar les biblioteques de baix nivell existents, reescriure a C++ les operacions d'administració de paquets restants a Python i moure la funcionalitat bàsica a una biblioteca separada amb la creació d'un enllaç al voltant d'aquesta biblioteca per preservar l'API de Python.
MICRODNF millora significativament lexperiència de lusuari i en el futur proporcionarà totes les funcions importants de DNF. També mantindrà tots els avantatges del MICRODNF original, com la mida mínima requerida pels contenidors.
La nova versió de Microdnf també utilitzarà el procés en segon pla DNF Daemon, reemplaçant la funcionalitat PackageKit i brindant una interfície per administrar paquets i actualitzacions en entorns gràfics. A diferència de PackageKit, DNF Daemon només admetrà el format RPM.
Està previst que Microdnf, libdnf5 i DNF Daemon s'enviïn juntament amb el kit d'eines DNF tradicional a la primera fase d'implementació. Quan es completi el projecte, el nou paquet reemplaçarà paquets com dnf, python3-dnf, python3-hawkey, libdnf, dnfdragora i python3-dnfdaemon.
De les àrees en què Microdnf és superior a DNF, es destaca: una indicació més visual del progrés de les operacions; implementació millorada de la taula de transaccions; la capacitat de mostrar informació en informes sobre transaccions completades que s'emet mitjançant scripts integrats a paquets (scriptlets); suport per utilitzar paquets RPM locals per a transaccions; sistema de finalització dentrada més avançat per a bash; suport per executar l'ordre builddep sense instal·lar Python al sistema.
Entre els desavantatges canviar l'administrador de paquets de distribució a Microdnf aquesta el canvi a l'estructura de les bases de dades internes i el processament de la base de dades separada de DNF, cosa que no li permetrà veure transaccions amb paquets realitzats a DNF a Microdnf i viceversa.
Els paquets instal·lats prèviament amb DNF es tractaran com a «instal·lats per l'usuari de l'historial de dnf» després de migrar a Microdnf, i la desinstal·lació d'un paquet instal·lat per un altre administrador de paquets no eliminarà les dependències no utilitzades associades amb DNF. A més, Microdnf no té previst mantenir al 100% la compatibilitat DNF a nivell d'ordres i opcions de línia d'ordres.
S'observa que la nova versió de Microdnf admetrà totes les funcions principals de DNF, però alhora conservarà un alt rendiment i compacitat.
Finalment si estàs interessat en poder conèixer més a l'respecte, pots consultar els detalls en el següent enllaç.
Sóc novell a la programació, i entusiasta a Linux. Mai he fet servir Fedora doncs sempre tinc un problema en la instal·lació i acabo en Debian (i derivades) o OpenSUSE. Però crec entendre la importància al món Linux, i el rellevant que el que passa a Fedora.
El meu dubte ve de la idea de substituir Python per C/C++, Perquè implementar amb un llenguatge de baix nivell que és molt criticat per les seves variants i el seu estàndard tan poc definit? Entenc una mica canviar d'un llenguatge interpretat a un compilat, però no entenc el salt a un llenguatge pel qual he vist que es busca fer servir menys en alguns àmbits. No seria millor haver fet servir Rust o C#?
No critico les decisions de la gent de Fedora, sinó buscar entendre com avança el món de la programació. Estic aprenent Python i JS a web, i vaig pensar a donar un bot posterior a C/C++ per les bases, així que aquesta nota em sembla podria ajudar-me amb l'enfocament.
Muchas gracias! Y excelente trabajo como siempre a la gente de <•DesdeLinux