Daniel Mach från Red Hat om början av utvecklingen av DNF 5-pakethanteraren, där DNF-logiken implementerad i Python kommer att överföras till libdnf-biblioteket skrivet i C++. DNF 5 är planerad att börja testas i juni under utvecklingen av Fedora 33, varefter den kommer att läggas till Rawhide-förvaret i oktober 2020 och kommer att ersätta DNF 2021 i februari 4. Underhållet av DNF 4-grenen kommer att fortsätta som det är används i Red Hat Enterprise Linux 8.
Det noteras att projektet har nått ett tillstånd där det är nästan omöjligt att fortsätta utveckla koden utan att bryta kompatibiliteten på API/ABI-nivå. Detta beror främst på relevansen av PackageKit och omöjligheten att utveckla libdnf utan att ändra "libhif" API. Samtidigt, trots avsikten att ändra API:t, sägs bibehållande av bakåtkompatibilitet på nivån för kommandoradsgränssnittet och API vara huvudprioritet.
Stöd för Python API i DNF kommer att behållas, men affärslogiken som skrivits i Python kommer att överföras till libdnf (C++) biblioteket, vilket kommer att säkerställa identisk funktion för pakethanteraren i distributionen. Utvecklingen kommer att centreras kring C++ API, och Python API kommer att genereras automatiskt i form av ett omslag baserat på det.
Bindningar för Go, Perl och
Rubin. Efter att C++ API har stabiliserats, kommer en C API att förberedas på dess bas, till vilken rpm-otree kommer att överföras. Python API kommer att tas bort och ersättas med Python API.
Kärnfunktionaliteten hos DNF kommer att behållas. På grund av den stora testsviten (cirka 1400 tester) förväntas det att API-omarbetningen inte kommer att påverka kommandoradsgränssnittet för slutanvändare. Parsning och utdata av argument kan ändras något, men dessa ändringar kommer att vara väl dokumenterade. I en avskalad version , som används i containrar, är det planerat att implementera en delmängd av DNF-kapacitet; att uppnå full funktionalitet övervägs inte.
I stället för En ny DBus-tjänst kommer att skapas som ger ett gränssnitt för hantering av paket och uppdateringar för grafiska applikationer. Den här tjänsten är planerad att utvecklas från grunden, så skapandet av den kan ta mycket tid. PackageKit har inte utvecklats nyligen och har varit i underhållsläge sedan 2014 på grund av förlust av relevans. Med utvecklingen av Snaps och Flatpak-system tappar distributioner intresset för PackageKit, till exempel är det inte längre tillgängligt i builds . Abstraktionslagret för pakethantering tillhandahålls till stor del av de inbyggda GNOME- och KDE-programkontrollcentren, som tillåter installation av flatpak-paket på individuell användarnivå. Det förenade systemets API för att få en lista över installerade paket är inte lika användbart som tidigare.
Källa: opennet.ru