Daniel Mach nga Red Hat për fillimin e zhvillimit të menaxherit të paketave DNF 5, ku do të transferohet logjika e zbatuar në gjuhën Python në bibliotekën libdnf, e shkruar në C++. Testimi i DNF 5 planifikohet të nisi në qershor gjatë procesit të zhvillimit të Fedora 33, pas së cilës do të shtohet në depozitën Rawhide në tetor 2020 dhe do të zëvendësojë DNF 4 në shkurt 2021. Mbështetja për degën DNF 4 do të vazhdojë, pasi ajo përdoret në Red Hat Enterprise Linux 8.
Vërehet se projekti ka arritur në një gjendje ku pothuajse është e pamundur të vazhdohet zhvillimi i kodit pa shkelur kompatibilitetin në nivelin API/ABI. Kryesisht kjo është e lidhur me e aktualitetit të PackageKit dhe pamundësinë e zhvillimit të libdnf pa ndryshimin e API «libhif». Ndërsa, pavarësisht nga qëllimi për të ndryshuar API, si prioritete kryesore përmenden ruajtja e kompatibilitetit prapa në nivelin e ndërfaqes së komandave dhe API.
Mbështetja për API-në Python në DNF do të ruhet, por logjika e biznesit e shkruar në Python do të transferohet në bibliotekën libdnf (C++), e cila do të garantojë identitetin e funksionimit të menaxherit të paketave në distribucion. Zhvillimi do të përqendrohet rreth API-së C++, dhe API-ja Python do të gjenerohet automatikisht në formën e një mbështetjeje në bazë të saj.
Njësoj do të formohen lidhjet për Go, Perl dhe
Ruby. Pas stabilizimit të API-së C++, një API C do të përpreparet në bazë të tij, në të cilin do të transferohet rpm-ostree. API-ja Python do të hiqet dhe do të zëvendësohet me API-në Python.
Funksionaliteti kryesor i DNF do të ruhet. Falë pranisës së një grupi të madh testuesish (rreth 1400 teste), pritet që ripërcaktimi i API-së të mos ndikojë në ndërfaqen e komandës për përdoruesit përfundimtarë. Mund të ketë disa ndryshime në analizën e argumenteve dhe në daljen e rezultateve, por këto ndryshime do të dokumentohen mirë. Në versionin e reduktuar , i aplikuar në kontejnerë, planifikohet të implementohet një nëngrup i mundësive të DNF, arritja e barazisë të plotë në funksionalitet nuk konsiderohet.
Në vend të do të krijohet një shërbim të ri DBus, i cili do të ofrojë një ndërfaqe për menaxhimin e paketave dhe përditësimeve për aplikacionet grafike. Ky shërbim planifikohet të zhvillohet nga fillimi, kështu që krijimi i tij mund të kërkojë shumë kohë. PackageKit ka qëndruar i papërmirësuar për një kohë të gjatë dhe është në modalitetin e mbështetjes që nga viti 2014 për shkak të humbjes së relevancës. Me avancimin e sistemeve Snaps dhe Flatpak, distribucioni po humbet interesin për PackageKit, për shembull, ai nuk përfshihet më në ndërtimet. . Niveli i abstraksionit për menaxhimin e paketave kryesisht përmirësohet nga Qendrat e menaxhimit të aplikacioneve GNOME dhe KDE, të cilat lejojnë instalimin e paketave flatpak në nivelin e përdoruesve individualë. Një API sistemik i unifikuar për të marrë listën e paketave të instaluara nuk është aq i dobishëm sa më parë.
Burimi: opennet.ru
