Daniel Mach Red Hatist rääkis DNF 5 paketihalduri arendamise algusest, kus Pythonis realiseeritud DNF loogika kantakse C++-s kirjutatud libdnf teeki. DNF 5 testimise algus on planeeritud juuniks Fedora 33 arendamise käigus, millele järgneb selle lisamine Rawhide'i repositooriumisse oktoobris 2020 ning DNF 4 asendamine veebruaris 2021. DNF 4 haru toetamine jätkub, kuna see on kasutusel Red Hat Enterprise Linux 8-s.
Tõdetakse, et projekt on jõudnud seisundisse, kus koodi arendamine on peaaegu võimatu ilma API/ABI tasandi ühilduvuse rikkumiseta. Peamiselt on see seotud ja libdnf arendamise võimatusega ilma „libhif“ API muutmata. Sellegipoolest, hoolimata kavatsusest API-d muuta, on peamiste prioriteetidena esitatud käskliidese ja API tagurpidi ühilduvuse säilitamine.
Python API tugi DNF jääb alles, kuid Pythonis kirjutatud äriloogika kantakse üle raamatukogusse libdnf (C++), mis tagab pakihalduri identse töö jaotises. Arendustöö keskendub C++ API-le, samas kui Python API genereeritakse automaatselt selle põhjal.
Sama juhtub ka Go, Perl ja
Ruby sidemete loomisega. Pärast C++ API stabiliseerimist valmistatakse selle põhjal ette ka C API, kuhu tõlgitakse rpm-ostree. Python API eemaldatakse ja asendatakse Python API-ga.
DNFi peamine funktsionaalsus jääb alles. Suure testikomplekti (umbes 1400 testi) tõttu on oodata, et API ümberkujundamine ei mõjuta lõppkasutajate käsurealiidest. Argumendi analüüs ja väljund võivad veidi muutuda, kuid need muudatused on hästi dokumenteeritud. Lühendatud versioonis , mida kasutatakse konteinerites, plaanitakse rakendada DNF-i võimaluste alamhulka, täieliku funktsionaalsuse pariteedi saavutamine ei ole kaalumisel.
Asetame loodakse uus DBus teenus, mis pakub liidest pakettide ja värskenduste haldamiseks graafilistes rakendustes. Seda teenust kavatsetakse arendada nullist, seega võib selle loomine võtta palju aega. PackageKit ei ole viimasel ajal arenenud ja on alates 2014. aastast säilitusrežiimis, kuna on kaotanud oma relevantsuse. Snaps ja Flatpak süsteemide edendamisega kaotavad distributsioonid huvi PackageKiti vastu, näiteks ei kaasata seda juba kogumitesse. . Pakettide haldamise abstraktsioonitase on suures osas tagatud GNOME ja KDE kohalike rakenduste halduskeskustega, mis võimaldavad installida flatpak-pakette üksikute kasutajate tasemel. Ühtne API installitud pakettide nimekirja saamiseks ei ole enam nii kasulik nagu varem.
Allikas: opennet.ru
