Gli sviluppatori di Fedora Linux intendono migrare la distribuzione a un nuovo gestore di pacchetti Microdnf, in sostituzione dell'attuale DNF. Il primo passo verso la migrazione sarà l'imminente aggiornamento significante di Microdnf previsto per il rilascio di Fedora Linux 38, che avrà funzionalità simili a DNF e in alcune aree persino superiori. Si segnala che la nuova versione di Microdnf supporterà tutte le principali funzionalità di DNF, mantenendo al contempo elevate prestazioni e compattezza.
La principale differenza tra Microdnf e DNF è l'utilizzo del linguaggio C per lo sviluppo, invece di Python, il che consente di eliminare molte dipendenze. Inizialmente, Microdnf è stato sviluppato come una versione ridotta di DNF da utilizzare in contenitori Docker, senza la necessità di installare Python. Ora gli sviluppatori di Fedora pianificano di portare Microdnf al livello di DNF e sostituire completamente DNF con Microdnf nel tempo.
Alla base di Microdnf c'è la libreria libdnf5, sviluppata nell'ambito del progetto DNF 5. L'idea principale di DNF 5 è di riscrivere le operazioni di base di gestione dei pacchetti in C++ e di estrarle in una libreria separata, creando attorno a questa libreria un'interfaccia per mantenere l'API Python.
La nuova versione di Microdnf utilizzerà anche un processo in background chiamato DNF Daemon, che sostituisce la funzionalità di PackageKit e fornisce un'interfaccia per la gestione dei pacchetti e degli aggiornamenti in ambienti grafici. A differenza di PackageKit, DNF Daemon supporterà solo il formato RPM.
Microdnf, libdnf5 e DNF Daemon nella prima fase di implementazione saranno forniti parallelamente all'uso degli strumenti tradizionali di DNF. Una volta che il progetto sarà completamente pronto, il nuovo pacchetto sostituirà i pacchetti come dnf, python3-dnf, python3-hawkey, libdnf, dnfdragora e python3-dnfdaemon.
Tra le aree in cui Microdnf supera DNF si segnalano: una visualizzazione più chiara del progresso delle operazioni; un'implementazione migliorata della tabella delle transazioni; la possibilità di riportare nel report delle transazioni le informazioni fornite dagli script incorporati nei pacchetti (scriplets); supporto per l'uso di pacchetti RPM locali per le transazioni; un sistema di completamento automatico dell'input più avanzato per bash; supporto per l'esecuzione del comando builddep senza installare Python nel sistema.
Tra i contro del passaggio del distribuito a Microdnf c'è il cambiamento nella struttura dei database interni e la gestione separata del database da DNF, il che non permetterà di vedere in Microdnf le transazioni con i pacchetti eseguite in DNF e viceversa. Inoltre, in Microdnf non si prevede di mantenere il 100% di compatibilità con DNF a livello di comandi e opzioni della riga di comando. Ci saranno anche alcune divergenze nel comportamento. Ad esempio, la rimozione di un pacchetto non porterà alla rimozione delle relative dipendenze che non sono utilizzate in altri pacchetti.
Fonte: opennet.ru
