Daniel Mach frÄn Red Hat angÄende starten av utvecklingen av paketförvaltaren DNF 5, dÀr logiken frÄn DNF, implementerad i Python, kommer att flyttas till biblioteket libdnf, skrivet i C++. Testning av DNF 5 planeras att börja i juni under utvecklingen av Fedora 33, och i oktober 2020 kommer den att lÀggas till i Rawhide-repositoriet, medan den i februari 2021 kommer att ersÀtta DNF 4. UnderhÄllet av DNF 4-grenen kommer att fortsÀtta, eftersom den anvÀnds i Red Hat Enterprise Linux 8.
Det noteras att projektet har nÄtt ett tillstÄnd dÀr det nÀstan Àr omöjligt att fortsÀtta utvecklingen av koden utan att bryta API\/ABI-kompatibiliteten. Detta beror frÀmst pÄ av relevansen för PackageKit och oförmÄgan att utveckla libdnf utan att Àndra API:t 'libhif'. Trots avsikten att förÀndra API:t nÀmns dock bevarande av bakÄtkompatibilitet pÄ nivÄn för kommandoradsgrÀnssnittet och API som högsta prioritet.
Stödet för Python API i DNF kommer att kvarstÄ, men den pÄ Python skrivna affÀrslogiken kommer att flyttas till biblioteket libdnf (C++), vilket kommer att garantera identisk funktionalitet för paketförvaltaren i distributionen. Utvecklingen kommer att fokuseras pÄ C++ API:t, medan Python API:t kommer att genereras automatiskt i form av en wrapper.
PÄ liknande sÀtt kommer bindningar att formas för Go, Perl och
Ruby. Efter att C++ API:t har stabiliserats kommer Àven C API:t att förberedas, som rpm-ostree kommer att översÀttas till. Python API:t kommer att tas bort och ersÀttas med Python API.
Den grundlÀggande funktionaliteten i DNF kommer att bevaras. Tack vare ett stort testset (ungefÀr 1400 tester) förvÀntas API-översynen inte pÄverka kommandoradsgrÀnssnittet för slutanvÀndarna. Det kan möjligen bli nÄgra Àndringar i analysen av argument och utdata, men dessa förÀndringar kommer att dokumenteras noggrant. I den nedskurna versionen , som anvÀnds i containrar, planeras ett delmÀngd av DNF:s funktioner, och att uppnÄ fullstÀndig paritet i funktionalitet övervÀgs inte.
IstÀllet för en ny DBus-tjÀnst kommer att skapas, som erbjuder ett grÀnssnitt för hantering av paket och uppdateringar för grafiska applikationer. Denna tjÀnst planeras att utvecklas frÄn grunden, sÄ dess skapelse kan ta lÄng tid. PackageKit har under de senaste Ären inte utvecklats och har varit i underhÄllslÀge sedan 2014 pÄ grund av bristande relevans. Med framvÀxten av Snaps- och Flatpak-systemen tappar distributioner intresset för PackageKit, till exempel ingÄr det inte lÀngre i versionerna. . AbstraktionsnivÄn för pakethantering sÀkerstÀlls i stor utstrÀckning av de inbyggda hanteringscentren för applikationer GNOME och KDE, som gör det möjligt att installera flatpak-paket pÄ nivÄer för enskilda anvÀndare. Ett enhetligt system-API för att fÄ en lista över installerade paket blir inte lika anvÀndbart som tidigare.
KĂ€lla: opennet.ru
