Daniel Mach fan Red Hat oer it begjin fan 'e ûntwikkeling fan' e DNF 5-pakketbehearder, wêryn de DNF-logika ymplementearre yn Python sil wurde oerbrocht nei de libdnf-bibleteek skreaun yn C ++. DNF 5 is pland om yn juny te begjinnen mei testen yn 'e ûntwikkeling fan Fedora 33, wêrnei't it yn oktober 2020 wurdt tafoege oan it Rawhide-repository, en sil DNF 2021 ferfange yn febrewaris 4. Underhâld fan' e DNF 4-tûke sil trochgean lykas it is brûkt yn Red Hat Enterprise Linux 8.
It wurdt opmurken dat it projekt in steat hat berikt wêryn it hast ûnmooglik is om de koade troch te gean sûnder kompatibiliteit te brekken op it API / ABI-nivo. Dit komt benammen troch de relevânsje fan PackageKit en de ûnmooglikheid om libdnf te ûntwikkeljen sûnder de "libhif" API te feroarjen. Tagelyk, nettsjinsteande de bedoeling om de API te feroarjen, wurdt it behâld fan efterkompatibiliteit op it nivo fan 'e kommandorigelynterface en API sein dat de haadprioriteit is.
Stipe foar de Python API yn DNF sil wurde behâlden, mar de saaklike logika skreaun yn Python wurdt oerbrocht nei de libdnf (C ++) bibleteek, dy't soarget foar de identike wurking fan de pakket manager yn de distribúsje. Untwikkeling sil sintraal wêze om de C ++ API, en de Python API sil automatysk wurde generearre yn 'e foarm fan in wrapper basearre op it.
Binings foar Go, Perl en
Ruby. Nei't de C ++ API is stabilisearre, sil in C API wurde taret op syn basis, wêrnei't rpm-ostree wurdt oerdroegen. Python API sil fuortsmiten wurde en ferfongen mei Python API.
De kearnfunksjonaliteit fan DNF sil behâlden wurde. Fanwegen de grutte testsuite (sawat 1400 tests), wurdt ferwachte dat de API-ferwurking gjin ynfloed hat op de kommandorigelynterface foar ein brûkers. It parsearjen en útfier fan arguminten kinne wat feroarje, mar dizze wizigingen sille goed dokumintearre wurde. Yn in stripped del ferzje , brûkt yn konteners, is it pland om in subset fan DNF-mooglikheden út te fieren; It realisearjen fan folsleine pariteit yn funksjonaliteit wurdt net beskôge.
Ynstee In nije DBus-tsjinst sil makke wurde dy't in ynterface leveret foar it behearen fan pakketten en updates foar grafyske applikaasjes. Dizze tsjinst is pland om fanôf it begjin te ûntwikkeljen, sadat it meitsjen fan it in protte tiid kin fereaskje. PackageKit is net koartlyn ûntwikkele en is sûnt 2014 yn ûnderhâldsmodus west fanwege ferlies fan relevânsje. Mei de foarútgong fan Snaps- en Flatpak-systemen ferlieze distribúsjes belangstelling foar PackageKit, it is bygelyks net mear beskikber yn builds . De abstraksjelaach foar pakketbehear wurdt foar in grut part fersoarge troch de native GNOME en KDE Application Control Centers, dy't ynstallaasje fan flatpak-pakketten op it yndividuele brûkersnivo mooglik meitsje. De ferienige systeem API foar it krijen fan in list mei ynstalleare pakketten is net sa nuttich as earder.
Boarne: opennet.ru