Daniel Mach de Red Hat pri la komenco de la disvolviĝo de la pakaĵmanaĝero DNF 5, en kiu la DNF-logiko efektivigita en Python estos translokigita al la libdnf-biblioteko skribita en C++. DNF 5 estas planita komenci testi en junio dum la disvolviĝo de Fedora 33, post kio ĝi estos aldonita al la deponejo de Rawhide en oktobro 2020, kaj anstataŭigos DNF 2021 en februaro 4. Prizorgado de la branĉo DNF 4 daŭros kiel ĝi estas. uzata en Red Hat Enterprise Linux 8.
Oni rimarkas, ke la projekto atingis staton, en kiu estas preskaŭ neeble daŭri disvolvi la kodon sen rompi kongruecon ĉe la API/ABI-nivelo. Ĉi tio estas ĉefe pro la graveco de PackageKit kaj la malebleco disvolvi libdnf sen ŝanĝi la "libhif" API. Samtempe, malgraŭ la intenco ŝanĝi la API, konservado de malantaŭa kongruo ĉe la nivelo de la komandlinia interfaco kaj API laŭdire estas la ĉefa prioritato.
Subteno por la Python API en DNF estos konservita, sed la komerca logiko skribita en Python estos transdonita al la libdnf (C++) biblioteko, kiu certigos la identan funkciadon de la pakaĵmanaĝero en la distribuo. Disvolviĝo estos centrita ĉirkaŭ la C++ API, kaj la Python API estos aŭtomate generita en la formo de envolvaĵo bazita sur ĝi.
Ligiloj por Go, Perl kaj
Ruby. Post kiam la C++ API estos stabiligita, C API estos preparita sur ĝia bazo, al kiu rpm-ostree estos transdonita. Python API estos forigita kaj anstataŭigita per Python API.
La kernfunkcieco de DNF estos retenita. Pro la granda testaro (ĉirkaŭ 1400 testoj), estas atendite, ke la API-relaboro ne influos la komandlinian interfacon por finaj uzantoj. Argumenta analizado kaj eligo povas iomete ŝanĝiĝi, sed ĉi tiuj ŝanĝoj estos bone dokumentitaj. En nudigita versio , uzita en ujoj, estas planite efektivigi subaron de DNF-kapabloj; atingi plenan egalecon en funkcieco ne estas pripensita.
Anstataŭe Nova servo DBus estos kreita, kiu disponigas interfacon por administri pakaĵojn kaj ĝisdatigojn por grafikaj aplikoj. Ĉi tiu servo estas planita esti disvolvita de nulo, do ĝia kreado povas postuli multan tempon. PackageKit ne estis evoluigita lastatempe kaj estis en funkciserva reĝimo ekde 2014 pro perdo de graveco. Kun la progreso de Snaps kaj Flatpak-sistemoj, distribuoj perdas intereson pri PackageKit, ekzemple, ĝi ne plu disponeblas en konstruoj. . La abstrakta tavolo por pakaĵadministrado estas plejparte provizita de la denaskaj GNOME kaj KDE-Aplikkontrolcentroj, kiuj permesas instalon de flatpak-pakaĵoj ĉe la individua uzantnivelo. La unuigita sistema API por ricevi liston de instalitaj pakaĵoj ne estas tiel utila kiel antaŭe.
fonto: opennet.ru