Daniel Mach nga Red Hat rreth fillimit të zhvillimit të menaxherit të paketave DNF 5, në të cilin logjika DNF e implementuar në Python do të transferohet në bibliotekën libdnf të shkruar në C++. DNF 5 është planifikuar të fillojë testimin në qershor gjatë zhvillimit të Fedora 33, pas së cilës do të shtohet në depo Rawhide në tetor 2020 dhe do të zëvendësojë DNF 2021 në shkurt 4. Mirëmbajtja e degës DNF 4 do të vazhdojë siç është përdoret në Red Hat Enterprise Linux 8.
Vihet re se projekti ka arritur një gjendje në të cilën është pothuajse e pamundur të vazhdohet me zhvillimin e kodit pa prishur përputhshmërinë në nivelin API/ABI. Kjo është kryesisht për shkak të rëndësia e PackageKit dhe pamundësia e zhvillimit të libdnf pa ndryshuar API-në "libhif". Në të njëjtën kohë, pavarësisht synimit për të ndryshuar API-në, ruajtja e përputhshmërisë së prapambetur në nivelin e ndërfaqes së linjës së komandës dhe API thuhet se është prioriteti kryesor.
Mbështetja për Python API 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ë sigurojë funksionimin identik të menaxherit të paketave në shpërndarje. Zhvillimi do të përqendrohet rreth C++ API dhe Python API do të gjenerohet automatikisht në formën e një mbështjellësi të bazuar në të.
Lidhjet për Go, Perl dhe
Rubin. Pasi të jetë stabilizuar API C++, mbi bazën e tij do të përgatitet një API C, tek e cila do të transferohet rpm-ostree. Python API do të hiqet dhe do të zëvendësohet me Python API.
Funksionaliteti kryesor i DNF do të ruhet. Për shkak të grupit të madh të testeve (rreth 1400 teste), pritet që ripërpunimi i API të mos ndikojë në ndërfaqen e linjës së komandës për përdoruesit fundorë. Analizimi i argumenteve dhe dalja mund të ndryshojnë pak, por këto ndryshime do të dokumentohen mirë. Në një version të zhveshur , i përdorur në kontejnerë, është planifikuar të zbatohet një nëngrup i aftësive DNF; arritja e barazisë së plotë në funksionalitet nuk merret parasysh.
Në vend të Do të krijohet një shërbim i ri DBus që ofron një ndërfaqe për menaxhimin e paketave dhe përditësimet për aplikacionet grafike. Ky shërbim është planifikuar të zhvillohet nga e para, kështu që krijimi i tij mund të kërkojë shumë kohë. PackageKit nuk është zhvilluar kohët e fundit dhe ka qenë në modalitetin e mirëmbajtjes që nga viti 2014 për shkak të humbjes së rëndësisë. Me avancimin e sistemeve Snaps dhe Flatpak, shpërndarjet po humbasin interesin për PackageKit, për shembull, ai nuk është më i disponueshëm në ndërtime . Shtresa e abstraksionit për menaxhimin e paketave sigurohet kryesisht nga Qendrat e Kontrollit të Aplikacionit GNOME dhe KDE amtare, të cilat lejojnë instalimin e paketave flatpak në nivelin individual të përdoruesit. Sistemi i unifikuar API për marrjen e një liste të paketave të instaluara nuk është aq i dobishëm sa më parë.
Burimi: opennet.ru