Daniel Mach dari Red Hat tentang awal pengembangan manajer paket DNF 5, di mana logika DNF yang diimplementasikan dengan Python akan ditransfer ke perpustakaan libdnf yang ditulis dalam C++. DNF 5 rencananya akan mulai diuji pada bulan Juni selama pengembangan Fedora 33, setelah itu akan ditambahkan ke repositori Rawhide pada bulan Oktober 2020, dan akan menggantikan DNF 2021 pada bulan Februari 4. Pemeliharaan cabang DNF 4 akan terus berlanjut sebagaimana adanya digunakan di Red Hat Enterprise Linux 8.
Perlu dicatat bahwa proyek ini telah mencapai keadaan di mana hampir tidak mungkin untuk terus mengembangkan kode tanpa merusak kompatibilitas pada tingkat API/ABI. Hal ini terutama disebabkan oleh relevansi PackageKit dan ketidakmungkinan mengembangkan libdnf tanpa mengubah API “libhif”. Pada saat yang sama, meskipun ada niat untuk mengubah API, menjaga kompatibilitas ke belakang pada tingkat antarmuka baris perintah dan API dikatakan sebagai prioritas utama.
Dukungan untuk API Python di DNF akan dipertahankan, tetapi logika bisnis yang ditulis dengan Python akan ditransfer ke perpustakaan libdnf (C++), yang akan memastikan operasi yang sama dari manajer paket dalam distribusi. Pengembangan akan dipusatkan di sekitar C++ API, dan Python API akan secara otomatis dihasilkan dalam bentuk pembungkus berdasarkan itu.
Binding untuk Go, Perl dan
Rubi. Setelah C++ API distabilkan, C API akan disiapkan berdasarkan basis tersebut, ke mana rpm-ostree akan ditransfer. Python API akan dihapus dan diganti dengan API Python.
Fungsi inti DNF akan dipertahankan. Karena rangkaian pengujian yang besar (sekitar 1400 pengujian), pengerjaan ulang API diharapkan tidak akan memengaruhi antarmuka baris perintah untuk pengguna akhir. Penguraian dan keluaran argumen mungkin sedikit berubah, namun perubahan ini akan didokumentasikan dengan baik. Dalam versi yang dipreteli , digunakan dalam container, direncanakan untuk mengimplementasikan subset kemampuan DNF; pencapaian paritas penuh dalam fungsionalitas tidak dipertimbangkan.
Alih-alih Layanan DBus baru akan dibuat yang menyediakan antarmuka untuk mengelola paket dan pembaruan untuk aplikasi grafis. Layanan ini rencananya akan dikembangkan dari awal, sehingga pembuatannya mungkin memerlukan banyak waktu. PackageKit belum dikembangkan baru-baru ini dan telah berada dalam mode pemeliharaan sejak tahun 2014 karena kehilangan relevansi. Dengan kemajuan sistem Snaps dan Flatpak, distribusi kehilangan minat terhadap PackageKit, misalnya, tidak lagi tersedia dalam versi build . Lapisan abstraksi untuk manajemen paket sebagian besar disediakan oleh Pusat Kontrol Aplikasi GNOME dan KDE asli, yang memungkinkan instalasi paket flatpak di tingkat pengguna individu. API sistem terpadu untuk mendapatkan daftar paket yang diinstal tidak berguna seperti sebelumnya.
Sumber: opennet.ru