Daniel Mach di Red Hat sull'inizio dello sviluppo del gestore di pacchetti DNF 5, in cui sarà effettuato il trasferimento della logica DNF implementata in Python nella libreria libdnf, scritta in C++. I test del DNF 5 sono previsti per iniziare a giugno durante lo sviluppo di Fedora 33, dopo di che verrà aggiunto nel repository Rawhide a ottobre 2020, e sostituito con il DNF 4 a febbraio 2021. Il supporto per il ramo 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 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 dichiarati sono il mantenimento della compatibilità retroattiva a livello di interfaccia della linea di comando e API.
Il supporto per l'API Python in DNF sarà mantenuto, ma la logica aziendale scritta in Python sarà trasferita nella libreria libdnf (C++), il che garantirà l'identità del funzionamento del gestore di pacchetti nella distribuzione. Lo sviluppo sarà incentrato attorno all'API C++, mentre l'API Python sarà generata automaticamente sotto forma di wrapper.
Allo stesso modo, verranno creati binding per Go, Perl e
Ruby. Dopo la stabilizzazione dell'API C++, sarà preparato anche un C API, su cui verrà migrato rpm-ostree. L'API Python sarà rimossa e sostituita da API Python.
La funzionalità principale di DNF sarà preservata. Grazie alla presenza di un ampio insieme di test (circa 1400 test), ci si aspetta che la revisione dell'API non influisca sull'interfaccia della linea di comando per gli utenti finali. Potrebbero esserci alcune modifiche nell'analisi degli argomenti e nell'output, ma queste modifiche saranno ben documentate. In una versione semplificata , utilizzata nei container, si prevede di implementare un sottoinsieme delle funzionalità di DNF, mentre il raggiungimento di una completa parità funzionale non è previsto.
Invece di verrà creato un nuovo servizio DBus, che fornirà un'interfaccia per la gestione dei pacchetti e degli aggiornamenti per applicazioni grafiche. Questo servizio è programmato per essere sviluppato da zero, quindi la sua creazione potrebbe richiedere molto tempo. PackageKit non si è sviluppato negli ultimi tempi 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ù incluso nelle build. . Il livello di astrazione per la gestione dei pacchetti è in gran parte garantito dai centri di gestione delle applicazioni GNOME e KDE, che permettono di installare pacchetti flatpak a livello di utenti singoli. Un'API di sistema unificata per ottenere un elenco dei pacchetti installati diventa meno utile rispetto al passato.
Fonte: opennet.ru
