Daniel Mach di Red Hat sull'inizio dello sviluppo del gestore pacchetti DNF 5, nel quale si prevede di trasferire la logica di DNF, attualmente scritta in Python, nella libreria libdnf, scritta in C++. I test per DNF 5 sono previsti per giugno, durante lo sviluppo di Fedora 33, con l'aggiunta al repository Rawhide nell'ottobre 2020 e la sostituzione di DNF 4 a febbraio 2021. Il supporto per DNF 4 continuerà, poiché è utilizzato in Red Hat Enterprise Linux 8.
Si osserva che il progetto ha raggiunto uno stato in cui è quasi impossibile continuare lo sviluppo del codice senza compromettere la compatibilità a livello di API/ABI. Questo è principalmente dovuto a di rilevanza di PackageKit e all'impossibilità di sviluppare libdnf senza modificare l'API di «libhif». Tuttavia, nonostante l'intenzione di cambiare l'API, i principali obiettivi restano la preservazione della compatibilità retroattiva a livello di interfaccia a riga di comando e API.
Il supporto per Python API in DNF sarà mantenuto, ma la logica di business scritta in Python sarà trasferita nella libreria libdnf (C++), garantendo così l'identità del funzionamento del gestore di pacchetti nella distribuzione. Lo sviluppo si concentrerà attorno all'API C++, mentre l'API Python sarà generata automaticamente come un wrapping sulla base di essa.
Analogamente, saranno formati i binding per Go, Perl e
Ruby. Dopo la stabilizzazione dell'API C++, sarà preparato anche un C API, su cui sarà migrato rpm-ostree. L'API Python sarà rimossa e sostituita con API Python.
La funzionalità principale di DNF sarà preservata. Grazie alla presenza di un ampio set di test (circa 1400 test), ci si aspetta che la riprogettazione dell'API non influisca sull'interfaccia a riga di comando per gli utenti finali. Potrebbero esserci alcune piccole variazioni nell'analisi degli argomenti e nell'output, ma queste modifiche saranno ben documentate. Nella versione ridotta, , utilizzata nei container, si prevede di implementare un sottoinsieme delle funzionalità di DNF; non si prevede di raggiungere la parità completa in termini di funzionalità.
Invece di verrà creato un nuovo servizio DBus, che fornirà un'interfaccia per la gestione dei pacchetti e degli aggiornamenti per le applicazioni grafiche. Questo servizio sarà sviluppato da zero, pertanto la sua creazione potrebbe richiedere molto tempo. PackageKit non è stato aggiornato di recente ed è in fase di mantenimento dal 2014 a causa della perdita di rilevanza. Con l'avvento dei sistemi Snaps e Flatpak, le distribuzioni stanno perdendo interesse per PackageKit; per esempio, non è più incluso nelle build. . Il livello di astrazione per la gestione dei pacchetti è in gran parte fornito dai centri di gestione delle applicazioni GNOME e KDE, che consentono l'installazione di pacchetti flatpak a livello di singoli utenti. Un'API di sistema unificata per ottenere l'elenco dei pacchetti installati non è più così utile come una volta.
Fonte: opennet.ru
