Daniel Mach van Red Hat oor die begin van die ontwikkeling van die DNF 5-pakketbestuurder, waarin die DNF-logika wat in Python geïmplementeer is, oorgedra sal word na die libdnf-biblioteek geskryf in C++. DNF 5 word beplan om in Junie te begin toets tydens die ontwikkeling van Fedora 33, waarna dit in Oktober 2020 by die Rawhide-bewaarplek gevoeg sal word, en sal DNF 2021 in Februarie 4 vervang. Die instandhouding van die DNF 4-tak sal voortgaan soos dit is gebruik in Red Hat Enterprise Linux 8.
Daar word kennis geneem dat die projek 'n toestand bereik het waarin dit byna onmoontlik is om voort te gaan met die ontwikkeling van die kode sonder om versoenbaarheid op die API/ABI-vlak te breek. Dit is hoofsaaklik as gevolg van die relevansie van PackageKit en die onmoontlikheid om libdnf te ontwikkel sonder om die "libhif" API te verander. Terselfdertyd, ten spyte van die voorneme om die API te verander, word gesê dat die handhawing van terugwaartse verenigbaarheid op die vlak van die opdragreëlkoppelvlak en API die hoofprioriteit is.
Ondersteuning vir die Python API in DNF sal behou word, maar die besigheidslogika wat in Python geskryf is, sal na die libdnf (C++) biblioteek oorgedra word, wat die identiese werking van die pakketbestuurder in die verspreiding sal verseker. Ontwikkeling sal rondom die C++ API gesentreer word, en die Python API sal outomaties gegenereer word in die vorm van 'n omhulsel wat daarop gebaseer is.
Bindings vir Go, Perl en
Ruby. Nadat die C++ API gestabiliseer is, sal 'n C API op die basis daarvan voorberei word, waarna rpm-otree oorgedra sal word. Python API sal verwyder word en vervang word met Python API.
Die kernfunksionaliteit van DNF sal behoue bly. As gevolg van die groot toetsreeks (ongeveer 1400 toetse), word verwag dat die API-herwerk nie die opdragreëlkoppelvlak vir eindgebruikers sal beïnvloed nie. Argumentontleding en -uitvoer kan effens verander, maar hierdie veranderinge sal goed gedokumenteer word. In 'n gestroopte weergawe , wat in houers gebruik word, word beplan om 'n subset van DNF-vermoëns te implementeer; die bereiking van volle gelykheid in funksionaliteit word nie oorweeg nie.
In plaas van 'n Nuwe DBus-diens sal geskep word wat 'n koppelvlak bied vir die bestuur van pakkette en opdaterings vir grafiese toepassings. Hierdie diens word beplan om van nuuts af ontwikkel te word, so die skepping daarvan kan baie tyd verg. PackageKit is nie onlangs ontwikkel nie en is sedert 2014 in onderhoudsmodus weens verlies aan relevansie. Met die vooruitgang van Snaps- en Flatpak-stelsels verloor verspreidings belangstelling in PackageKit, dit is byvoorbeeld nie meer beskikbaar in builds nie . Die abstraksielaag vir pakketbestuur word grootliks verskaf deur die inheemse GNOME- en KDE-toepassingsbeheersentrums, wat die installering van flatpak-pakkette op die individuele gebruikervlak moontlik maak. Die verenigde stelsel-API om 'n lys van geïnstalleerde pakkette te kry, is nie so nuttig soos voorheen nie.
Bron: opennet.ru