Daniel Mach de la Red Hat despre începutul dezvoltării managerului de pachete DNF 5, în care logica DNF implementată în Python va fi transferată în biblioteca libdnf scrisă în C++. DNF 5 este planificat să înceapă testarea în iunie în timpul dezvoltării Fedora 33, după care va fi adăugat la depozitul Rawhide în octombrie 2020 și va înlocui DNF 2021 în februarie 4. Întreținerea sucursalei DNF 4 va continua așa cum este. utilizat în Red Hat Enterprise Linux 8.
Se observă că proiectul a ajuns într-o stare în care este aproape imposibil să continui dezvoltarea codului fără a întrerupe compatibilitatea la nivel API/ABI. Acest lucru se datorează în principal relevanța PackageKit și imposibilitatea dezvoltării libdnf fără a schimba API-ul „libhif”. În același timp, în ciuda intenției de a schimba API-ul, se spune că menținerea compatibilității cu înapoi la nivelul interfeței liniei de comandă și a API-ului este prioritatea principală.
Suportul pentru API-ul Python în DNF va fi păstrat, dar logica de afaceri scrisă în Python va fi transferată în biblioteca libdnf (C++), care va asigura funcționarea identică a managerului de pachete în distribuție. Dezvoltarea va fi centrată în jurul API-ului C++, iar API-ul Python va fi generat automat sub forma unui wrapper bazat pe acesta.
Legături pentru Go, Perl și
Rubin. După ce API-ul C++ a fost stabilizat, pe baza acestuia va fi pregătit un API C, la 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 păstrată. Datorită suitei mari de teste (aproximativ 1400 de teste), este de așteptat ca reluarea API-ului să nu afecteze interfața liniei de comandă pentru utilizatorii finali. Analiza și ieșirea argumentelor se pot schimba ușor, dar aceste modificări vor fi bine documentate. Într-o versiune redusă , utilizat în containere, este planificată implementarea unui subset de capabilități DNF; nu se ia în considerare obținerea parității depline în funcționalitate.
În loc de Va fi creat un nou serviciu DBus care oferă 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 lui poate necesita mult timp. PackageKit nu a fost dezvoltat recent și se află în modul de întreținere din 2014 din cauza pierderii relevanței. Odată cu avansarea sistemelor Snaps și Flatpak, distribuțiile își pierd interesul pentru PackageKit, de exemplu, acesta nu mai este disponibil în versiuni . Stratul de abstractizare pentru gestionarea pachetelor este furnizat în mare parte de centrele native de control al aplicațiilor GNOME și KDE, care permit instalarea pachetelor flatpak la nivel de utilizator individual. API-ul de sistem unificat pentru obținerea unei liste de pachete instalate nu este la fel de util ca înainte.
Sursa: opennet.ru