Recentemente il Gli sviluppatori di Fedora hanno reso note le loro intenzioni di migrare chiamata la distribuzione al nuovo gestore di pacchetti “Microdnf” invece dal gestore di pacchetti "DNF" che è attualmente utilizzato.
Il primo passo verso la migrazione sarà un importante aggiornamento di Microdnf, previsto per Fedora 38, che si avvicinerà in termini di funzionalità a DNF e addirittura lo supererà in alcune aree.
Si è detto che le intenzioni per effettuare questa migrazione è dovuto la differenza chiave tra Microdnf e DNF è l'uso di C invece di Python per lo sviluppo, che ti permette di sbarazzarti di molte dipendenze.
A un certo punto, DNF ha sostituito Yum, che è stato scritto interamente in Python, e in DNF, le funzioni di basso livello che richiedono prestazioni sono state riscritte e spostate in librerie C separate hawkey, librepo, libsolv e libcomps, ma il framework e l'alto- i componenti di livello sono rimasti nel linguaggio Python.
Microdnf è stato originariamente sviluppato come una versione semplificata di DNF per l'uso in contenitori Docker che non richiedevano l'installazione di Python. Ora gli sviluppatori di Fedora hanno in programma di portare Microdnf al livello di funzionalità DNF e alla fine sostituire completamente DNF con Microdnf.
Un importante aggiornamento di Microdnf è il primo passo nell'evoluzione della gestione dei pacchetti in Fedora. Il nuovo microdnf ha l'ambizione di fornire tutte le funzionalità principali di DNF senza perdere il suo ingombro minimo.
Microdnf è basato sulla libreria libdnf5, sviluppato come parte del progetto DNF 5. DNF 5 mira a unificare le librerie di basso livello esistenti, riscrivere le restanti operazioni di gestione dei pacchetti Python in C++ e spostare le funzionalità principali in una libreria separata con la creazione di un'associazione attorno a questa libreria per preservare il API Python.
MICRODNF migliora significativamente l'esperienza dell'utente e fornirà tutte le importanti funzionalità di DNF in futuro. Manterrà inoltre tutti i vantaggi del MICRODNF originale, come la dimensione minima richiesta per i contenitori.
La nuova versione di Microdnf utilizzerà anche il processo in background DNF Daemon, sostituendo la funzionalità PackageKit e fornendo un'interfaccia per la gestione di pacchetti e aggiornamenti in ambienti grafici. A differenza di PackageKit, DNF Daemon supporterà solo il formato RPM.
Microdnf, libdnf5 e DNF Daemon dovrebbero essere spediti insieme al tradizionale toolkit DNF nella prima fase di implementazione. Una volta completato il progetto, il nuovo pacchetto sostituirà pacchetti come dnf, python3-dnf, python3-hawkey, libdnf, dnfdragora e python3-dnfdaemon.
Del aree in cui Microdnf è superiore a DNF, si distingue: un'indicazione più visiva dell'andamento delle operazioni; migliore implementazione della tabella delle transazioni; la capacità di visualizzare le informazioni nei rapporti sulle transazioni completate emesse da scriptlet pacchettizzati (scriptlet); supporto per l'utilizzo di pacchetti RPM locali per le transazioni; sistema di completamento degli input più avanzato per bash; supporto per eseguire il comando builddep senza installare Python sul sistema.
Tra gli svantaggi cambiando il gestore dei pacchetti della distribuzione in Microdnf è il cambiamento nella struttura dei database interni e l'elaborazione del database separato da DNF, che non consentirà di visualizzare le transazioni con i pacchetti effettuati in DNF in Microdnf e viceversa.
I pacchetti precedentemente installati con DNF verranno trattati come "installati dall'utente dalla cronologia dnf" dopo la migrazione a Microdnf e la disinstallazione di un pacchetto installato da un altro gestore di pacchetti non rimuoverà le dipendenze inutilizzate ad esso associate. Inoltre, Microdnf non prevede di mantenere il supporto DNF al 100% a livello di comando e opzioni della riga di comando.
Si segnala che la nuova versione di Microdnf supporterà tutte le principali funzionalità di DNF, ma allo stesso tempo manterrà elevate prestazioni e compattezza.
Infine, se sei interessato a poterne saperne di più, puoi consultare i dettagli nel seguente link.
Sono nuovo nella programmazione e sono entusiasta di Linux. Non ho mai usato Fedora perché ho sempre problemi con l'installazione e finisco con Debian (e derivati) o OpenSUSE. Ma penso di capire l'importanza nel mondo Linux e quanto sia rilevante ciò che accade in Fedora.
Il mio dubbio nasce dall'idea di sostituire Python al C/C++, perché implementare con un linguaggio di basso livello che è stato molto criticato per le sue varianti e il suo standard poco definito? Capisco un po' il passaggio da un linguaggio interpretato a uno compilato, ma non capisco il passaggio a un linguaggio per il quale ho visto che si cerca di usare meno in alcune aree. Non sarebbe stato meglio usare Rust o C# ?
Non critico le decisioni del popolo di Fedora, ma cerco di capire come avanza il mondo della programmazione. Sto imparando Python e JS sul Web e ho pensato di tornare in C/C++ per le basi, quindi questa nota sembra che potrebbe aiutarmi a concentrarmi.
Grazie mille! E ottimo lavoro come sempre per le persone di <•DesdeLinux