Daniel Mach de la Red Hat cu privire la începutul dezvoltării managerului de pachete DNF 5, în care va fi realizată transferul logicii DNF, implementată în limba Python, în biblioteca libdnf, scrisă în C++. Testarea DNF 5 este planificată să înceapă în luna iunie în cadrul dezvoltării Fedora 33, după care, în octombrie 2020, va fi adăugată în repository-ul Rawhide, iar în februarie 2021 va înlocui DNF 4. Sprijinirea versiunii DNF 4 va continua, deoarece aceasta este utilizată în Red Hat Enterprise Linux 8.
Se remarcă faptul că proiectul a ajuns într-o stare în care este aproape imposibil să se continue dezvoltarea codului fără a încălca compatibilitatea la nivel de API/ABI. Acest lucru se datorează în principal relevanței PackageKit și imposibilității de a dezvolta libdnf fără a schimba API-ul „libhif”. Cu toate acestea, în ciuda intenției de a schimba API-ul, principalele priorități includ păstrarea compatibilității retroactive la nivel de interfață de linie de comandă și API.
Suportul pentru API-ul Python în DNF va fi menținut, dar logica de afaceri scrisă în Python va fi transferată în biblioteca libdnf (C++), ceea ce va garanta identitatea funcționării managerului de pachete în distribuție. Dezvoltarea se va concentra pe API-ul C++, iar API-ul Python va fi generat automat sub formă de wrapper pe baza acestuia.
În mod similar, vor fi create legături pentru Go, Perl și
Ruby. După stabilizarea API-ului C++, va fi pregătit și API-ul C, pe care va fi transferat rpm-ostree. API-ul Python va fi eliminat și înlocuit cu API-ul Python.
Funcționalitatea de bază a DNF va fi menținută. Datorită existenței unui set mare de teste (aproximativ 1400 de teste), se așteaptă ca reproiectarea API-ului să nu afecteze interfața de linie de comandă pentru utilizatorii finali. Este posibil să existe mici modificări în analiza argumentelor și ieșire, dar aceste modificări vor fi bine documentate. În versiunea redactată , utilizată în container, se preconizează implementarea unui subansamblu de funcționalități DNF; atingerea unei parități complete în funcționalitate nu este luată în considerare.
În loc de va fi creat un nou serviciu DBus, care va oferi o interfață pentru gestionarea pachetelor și actualizărilor pentru aplicațiile grafice. Acest serviciu este planificat să fie dezvoltat de la zero, așa că crearea sa ar putea necesita mult timp. PackageKit nu a mai fost dezvoltat în ultima vreme și se află în regim de întreținere din 2014 din cauza pierderii relevanței. Odată cu promovarea sistemelor Snaps și Flatpak, distribuțiile își pierd interesul pentru PackageKit, de exemplu, aceasta nu mai este inclusă în pachetele sale. . Nivelul de abstractizare pentru gestionarea pachetelor este în mare parte asigurat de centrele de gestionare a aplicațiilor GNOME și KDE, care permit instalarea pachetelor flatpak la nivelul utilizatorilor individuali. API-ul sistemului unificat pentru obținerea listei de pachete instalate devine nu atât de util precum era înainte.
Sursa: opennet.ro
