การพัฒนาตัวจัดการแพ็คเกจ DNF 5 และการแทนที่ PackageKit ได้เริ่มขึ้นแล้ว

แดเนียล มัค จาก Red Hat сообщил เกี่ยวกับจุดเริ่มต้นของการพัฒนาตัวจัดการแพ็คเกจ DNF 5 ซึ่งตรรกะ DNF ที่ใช้ใน Python จะถูกถ่ายโอนไปยังไลบรารี libdnf ที่เขียนด้วย C ++ DNF 5 มีแผนที่จะเริ่มการทดสอบในเดือนมิถุนายนระหว่างการพัฒนา Fedora 33 หลังจากนั้นจะถูกเพิ่มไปยังพื้นที่เก็บข้อมูล Rawhide ในเดือนตุลาคม 2020 และจะแทนที่ DNF 2021 ในเดือนกุมภาพันธ์ 4 การบำรุงรักษาสาขา DNF 4 จะยังคงดำเนินต่อไปเหมือนเดิม ใช้ใน Red Hat Enterprise Linux 8

มีข้อสังเกตว่าโครงการถึงสถานะที่แทบจะเป็นไปไม่ได้เลยที่จะพัฒนาโค้ดต่อไปโดยไม่ทำลายความเข้ากันได้ในระดับ API/ABI สาเหตุหลักมาจาก การสูญเสีย ความเกี่ยวข้องของ PackageKit และความเป็นไปไม่ได้ในการพัฒนา libdnf โดยไม่ต้องเปลี่ยน API “libhif” ในเวลาเดียวกันแม้จะมีความตั้งใจที่จะเปลี่ยน API แต่การรักษาความเข้ากันได้แบบย้อนหลังในระดับอินเทอร์เฟซบรรทัดคำสั่งและ API ถือเป็นลำดับความสำคัญหลัก

การรองรับ Python API ใน DNF จะยังคงอยู่ แต่ตรรกะทางธุรกิจที่เขียนด้วย Python จะถูกโอนไปยังไลบรารี libdnf (C++) ซึ่งจะทำให้มั่นใจว่าการทำงานที่เหมือนกันของตัวจัดการแพ็คเกจในการแจกจ่าย การพัฒนาจะมีศูนย์กลางอยู่ที่ C++ API และ Python API จะถูกสร้างขึ้นโดยอัตโนมัติในรูปแบบของ wrapper ตามมัน
การผูกสำหรับ Go, Perl และ
ทับทิม. หลังจากที่ C++ API เสถียรแล้ว C API จะถูกจัดเตรียมบนพื้นฐานของมัน ซึ่ง rpm-ostree จะถูกถ่ายโอนไปยัง ฮอว์กี้ Python API จะถูกลบออกและแทนที่ด้วย libdnf หลาม API

ฟังก์ชันการทำงานหลักของ DNF จะยังคงอยู่ เนื่องจากชุดการทดสอบขนาดใหญ่ (การทดสอบประมาณ 1400 รายการ) คาดว่าการทำงานซ้ำ API จะไม่ส่งผลกระทบต่ออินเทอร์เฟซบรรทัดคำสั่งสำหรับผู้ใช้ปลายทาง การแยกวิเคราะห์อาร์กิวเมนต์และเอาต์พุตอาจมีการเปลี่ยนแปลงเล็กน้อย แต่การเปลี่ยนแปลงเหล่านี้จะได้รับการบันทึกไว้อย่างดี ในเวอร์ชั่นที่แยกออกมา ไมโครดีเอ็นเอฟซึ่งใช้ในคอนเทนเนอร์ มีการวางแผนที่จะใช้ชุดย่อยของความสามารถ DNF โดยไม่ถือว่าบรรลุความเท่าเทียมกันอย่างสมบูรณ์ในการทำงาน

แทนการ แพ็คเกจ บริการ DBus ใหม่จะถูกสร้างขึ้นซึ่งมีอินเทอร์เฟซสำหรับการจัดการแพ็คเกจและการอัพเดตสำหรับแอปพลิเคชันกราฟิก บริการนี้ได้รับการวางแผนให้พัฒนาตั้งแต่เริ่มต้น ดังนั้นการสร้างอาจต้องใช้เวลามาก PackageKit ไม่ได้รับการพัฒนาเมื่อเร็วๆ นี้ และอยู่ในโหมดการบำรุงรักษามาตั้งแต่ปี 2014 เนื่องจากสูญเสียความเกี่ยวข้อง ด้วยความก้าวหน้าของระบบ Snaps และ Flatpak การแจกแจงจึงหมดความสนใจใน PackageKit เช่น ไม่มีในบิลด์อีกต่อไป Fedora สีเงินสีฟ้า. เลเยอร์นามธรรมสำหรับการจัดการแพ็คเกจส่วนใหญ่มาจาก GNOME และ KDE Application Control Centers ดั้งเดิม ซึ่งอนุญาตให้ติดตั้งแพ็คเกจ flatpak ในระดับผู้ใช้แต่ละราย API ระบบรวมสำหรับการรับรายการแพ็คเกจที่ติดตั้งไม่มีประโยชน์เหมือนเมื่อก่อน

ที่มา: opennet.ru