Daniel Mach từ Red Hat về sự khởi đầu của quá trình phát triển trình quản lý gói DNF 5, trong đó logic DNF được triển khai bằng Python sẽ được chuyển sang thư viện libdnf được viết bằng C++. DNF 5 dự kiến bắt đầu thử nghiệm vào tháng 33 trong quá trình phát triển Fedora 2020, sau đó nó sẽ được thêm vào kho Rawhide vào tháng 2021 năm 4 và sẽ thay thế DNF 4 vào tháng 8 năm XNUMX. Việc bảo trì nhánh DNF XNUMX sẽ tiếp tục như cũ được sử dụng trong Red Hat Enterprise Linux XNUMX.
Cần lưu ý rằng dự án đã đạt đến trạng thái gần như không thể tiếp tục phát triển mã mà không phá vỡ tính tương thích ở cấp API/ABI. Điều này chủ yếu là do mức độ liên quan của PackageKit và việc không thể phát triển libdnf mà không thay đổi API “libhif”. Đồng thời, mặc dù có ý định thay đổi API nhưng việc duy trì khả năng tương thích ngược ở cấp độ giao diện dòng lệnh và API được cho là ưu tiên chính.
Hỗ trợ cho API Python trong DNF sẽ được giữ lại, nhưng logic nghiệp vụ được viết bằng Python sẽ được chuyển sang thư viện libdnf (C++), thư viện này sẽ đảm bảo hoạt động giống hệt của trình quản lý gói trong bản phân phối. Việc phát triển sẽ tập trung vào API C++ và API Python sẽ được tạo tự động dưới dạng trình bao bọc dựa trên nó.
Các ràng buộc cho Go, Perl và
Ruby. Sau khi API C++ được ổn định, API C sẽ được chuẩn bị trên cơ sở đó, mà RPM-ostree sẽ được chuyển đến. API Python sẽ bị xóa và thay thế bằng API Python.
Chức năng cốt lõi của DNF sẽ được giữ lại. Do bộ thử nghiệm lớn (khoảng 1400 thử nghiệm), dự kiến việc làm lại API sẽ không ảnh hưởng đến giao diện dòng lệnh cho người dùng cuối. Việc phân tích cú pháp và kết quả đầu ra có thể thay đổi đôi chút nhưng những thay đổi này sẽ được ghi lại đầy đủ. Trong một phiên bản rút gọn , được sử dụng trong các thùng chứa, nó được lên kế hoạch triển khai một tập hợp con các khả năng DNF; việc đạt được sự tương đương hoàn toàn về chức năng không được xem xét.
Thay vì Một dịch vụ DBus mới sẽ được tạo ra để cung cấp giao diện quản lý các gói và bản cập nhật cho các ứng dụng đồ họa. Dịch vụ này được lên kế hoạch phát triển từ đầu nên việc tạo ra nó có thể mất nhiều thời gian. PackageKit gần đây không được phát triển và đã ở chế độ bảo trì từ năm 2014 do không còn phù hợp. Với sự tiến bộ của hệ thống Snaps và Flatpak, các bản phân phối đang mất dần sự quan tâm đến PackageKit, chẳng hạn, nó không còn có sẵn trong các bản dựng . Lớp trừu tượng để quản lý gói phần lớn được cung cấp bởi Trung tâm kiểm soát ứng dụng Gnome và KDE gốc, cho phép cài đặt các gói Flatpak ở cấp độ người dùng cá nhân. API hệ thống thống nhất để nhận danh sách các gói đã cài đặt không còn hữu ích như trước.
Nguồn: opennet.ru