Daniels Maks no Red Hat par DNF 5 pakotņu pārvaldnieka izstrādes sākumu, kurā Python ieviestā DNF loģika tiks pārnesta uz C++ rakstīto libdnf bibliotēku. Plānots, ka DNF 5 testēšanu sāks jūnijā Fedora 33 izstrādes laikā, pēc tam 2020. gada oktobrī tas tiks pievienots Rawhide krātuvei un 2021. gada februārī aizstās DNF 4. DNF 4 filiāles uzturēšana turpināsies, kā tas ir izmanto Red Hat Enterprise Linux 8.
Tiek atzīmēts, ka projekts ir sasniedzis stāvokli, kurā ir gandrīz neiespējami turpināt izstrādāt kodu, nepārkāpjot saderību API/ABI līmenī. Tas galvenokārt ir saistīts ar PackageKit atbilstība un neiespējamība izstrādāt libdnf, nemainot “libhif” API. Tajā pašā laikā, neskatoties uz nodomu mainīt API, galvenā prioritāte ir saglabāt atpakaļejošu saderību komandrindas interfeisa un API līmenī.
Python API atbalsts DNF tiks saglabāts, bet Python rakstītā biznesa loģika tiks pārnesta uz libdnf (C++) bibliotēku, kas nodrošinās identisku pakotņu pārvaldnieka darbību izplatīšanā. Izstrāde tiks centrēta ap C++ API, un Python API tiks automātiski ģenerēta iesaiņojuma veidā, pamatojoties uz to.
Iesējumi priekš Go, Perl un
Rubīns. Pēc C++ API stabilizēšanas uz tās bāzes tiks sagatavota C API, uz kuru tiks pārsūtīts rpm-ostree. Python API tiks noņemta un aizstāta ar Python API.
DNF galvenā funkcionalitāte tiks saglabāta. Lielā testa komplekta (apmēram 1400 testu) dēļ ir sagaidāms, ka API pārstrādāšana neietekmēs galalietotāju komandrindas saskarni. Argumentu parsēšana un izvade var nedaudz mainīties, taču šīs izmaiņas būs labi dokumentētas. Atkailinātā versijā , ko izmanto konteineros, plānots ieviest DNF iespēju apakškopu, pilnīgas funkcionalitātes paritātes sasniegšana netiek apsvērta.
Tā vietā, lai Tiks izveidots jauns DBus pakalpojums, kas nodrošina interfeisu grafisko lietojumprogrammu pakotņu un atjauninājumu pārvaldībai. Šo servisu plānots izstrādāt no nulles, tāpēc tā izveide var prasīt daudz laika. PackageKit nesen nav izstrādāts un kopš 2014. gada ir bijis uzturēšanas režīmā, jo tiek zaudēta nozīme. Attīstoties Snaps un Flatpak sistēmām, izplatīšana zaudē interesi par PackageKit, piemēram, tas vairs nav pieejams būvējumos. . Pakešu pārvaldības abstrakcijas slāni lielākoties nodrošina vietējie GNOME un KDE lietojumprogrammu vadības centri, kas ļauj instalēt flatpak pakotnes individuālā lietotāja līmenī. Vienotā sistēmas API instalēto pakotņu saraksta iegūšanai nav tik noderīga kā iepriekš.
Avots: opennet.ru