Daniel Mach di RedHat sull'inizio dello sviluppo del gestore di pacchetti DNF 5, in cui la logica DNF implementata in Python verrà trasferita nella libreria libdnf scritta in C++. Si prevede che DNF 5 inizi i test a giugno durante lo sviluppo di Fedora 33, dopodiché verrà aggiunto al repository Rawhide nell'ottobre 2020 e sostituirà DNF 2021 nel febbraio 4. La manutenzione del ramo DNF 4 continuerà così com'è utilizzato in Red Hat Enterprise Linux 8.
Va notato che il progetto ha raggiunto uno stato in cui è quasi impossibile continuare a sviluppare il codice senza interrompere la compatibilità a livello API/ABI. Ciò è dovuto principalmente a la rilevanza di PackageKit e l'impossibilità di sviluppare libdnf senza modificare l'API “libhif”. Allo stesso tempo, nonostante l’intenzione di modificare l’API, la priorità principale sarebbe mantenere la compatibilità con le versioni precedenti a livello dell’interfaccia della riga di comando e dell’API.
Il supporto per l'API Python in DNF verrà mantenuto, ma la logica aziendale scritta in Python verrà trasferita alla libreria libdnf (C++), che garantirà l'identico funzionamento del gestore pacchetti nella distribuzione. Lo sviluppo sarà incentrato sull'API C++ e l'API Python verrà generata automaticamente sotto forma di wrapper basato su di essa.
Collegamenti per Go, Perl e
Rubino. Dopo che l'API C++ è stata stabilizzata, sulla base verrà preparata un'API C, nella quale verrà trasferito rpm-ostree. L'API Python verrà rimossa e sostituita con API Python.
La funzionalità principale di DNF verrà mantenuta. A causa dell'ampia suite di test (circa 1400 test), si prevede che la rielaborazione dell'API non avrà alcun impatto sull'interfaccia della riga di comando per gli utenti finali. L'analisi e l'output degli argomenti potrebbero cambiare leggermente, ma tali modifiche saranno ben documentate. In versione ridotta , utilizzato nei contenitori, si prevede di implementare un sottoinsieme di funzionalità DNF; non è considerato il raggiungimento della piena parità di funzionalità.
Invece di Verrà creato un nuovo servizio DBus che fornisce un'interfaccia per la gestione dei pacchetti e degli aggiornamenti per le applicazioni grafiche. Questo servizio è progettato per essere sviluppato da zero, quindi la sua creazione potrebbe richiedere molto tempo. PackageKit non è stato sviluppato di recente ed è in modalità di manutenzione dal 2014 a causa della perdita di rilevanza. Con l'avanzamento dei sistemi Snaps e Flatpak, le distribuzioni stanno perdendo interesse per PackageKit, ad esempio non è più disponibile nelle build . Il livello di astrazione per la gestione dei pacchetti è in gran parte fornito dai centri di controllo delle applicazioni native di GNOME e KDE, che consentono l'installazione di pacchetti flatpak a livello di singolo utente. L'API di sistema unificato per ottenere un elenco dei pacchetti installati non è così utile come prima.
Fonte: opennet.ru