Vor kurzem die Die Fedora-Entwickler haben ihre Migrationsabsichten bekannt gegeben die Verteilung an den neuen Paketmanager namens Stattdessen „Microdnf“. vom Paketmanager "DNF" das aktuell verwendet wird.
Der erste Schritt auf dem Weg zur Migration wird ein großes Update für Microdnf sein, geplant für Fedora 38, das in seiner Funktionalität DNF nahe kommen und es in einigen Bereichen sogar übertreffen wird.
Es wird das erwähnt die Absichten zur Durchführung dieser Migration ist fällig Der Hauptunterschied zwischen Microdnf und DNF ist die Verwendung von C anstelle von Python für die Entwicklung, die ermöglicht es Ihnen, viele Abhängigkeiten loszuwerden.
Irgendwann ersetzte DNF Yum, das vollständig in Python geschrieben wurde, und in DNF wurden leistungsintensive Low-Level-Funktionen umgeschrieben und in separate Hawkey-, librepo-, libsolv- und libcomps-C-Bibliotheken verschoben, aber das Framework und die High- Level-Komponenten blieben in der Python-Sprache.
Microdnf wurde ursprünglich als vereinfachte Version von DNF entwickelt zur Verwendung in Docker-Containern, für die keine Installation von Python erforderlich war. Nun planen die Fedora-Entwickler, Microdnf auf die Ebene der DNF-Funktionalität zu bringen und DNF schließlich vollständig durch Microdnf zu ersetzen.
Ein großes Update für Microdnf ist der erste Schritt in der Entwicklung der Paketverwaltung in Fedora. Das neue microdnf hat den Ehrgeiz, alle Kernfunktionen von DNF bereitzustellen, ohne seinen minimalen Platzbedarf zu verlieren.
Microdnf basiert auf der libdnf5-Bibliothek, entwickelt als Teil des DNF 5-Projekts DNF 5 zielt darauf ab, vorhandene Low-Level-Bibliotheken zu vereinheitlichen, die verbleibenden Python-Paketverwaltungsvorgänge in C++ neu zu schreiben und die Kernfunktionalität in eine separate Bibliothek zu verschieben, wobei eine Bindung um diese Bibliothek erstellt wird, um die Python-API.
MICRODNF verbessert die Benutzererfahrung erheblich und wird in Zukunft alle wichtigen Funktionen von DNF bereitstellen. Es behält auch alle Vorteile des ursprünglichen MICRODNF bei, wie z. B. die erforderliche Mindestgröße für Container.
Die neue Version von Microdnf verwendet auch den Hintergrundprozess DNF Daemon, Ersetzen der PackageKit-Funktionalität und Bereitstellen einer Schnittstelle zum Verwalten von Paketen und Updates in grafischen Umgebungen. Im Gegensatz zu PackageKit unterstützt der DNF-Daemon nur das RPM-Format.
Microdnf, libdnf5 und der DNF-Daemon sollen in der ersten Implementierungsphase zusammen mit dem traditionellen DNF-Toolkit ausgeliefert werden. Sobald das Projekt abgeschlossen ist, wird das neue Paket Pakete wie dnf, python3-dnf, python3-hawkey, libdnf, dnfdragora und python3-dnfdaemon ersetzen.
Von der Bereiche, in denen Microdnf DNF überlegen ist, sticht es hervor: eine visuellere Anzeige des Betriebsfortschritts; verbesserte Transaktionstabellenimplementierung; die Fähigkeit, Informationen in Berichten über abgeschlossene Transaktionen anzuzeigen, die von gepackten Skriptlets (Scriptlets) ausgegeben werden; Unterstützung für die Verwendung lokaler RPM-Pakete für Transaktionen; fortschrittlicheres Eingabevervollständigungssystem für bash; Unterstützung für die Ausführung des builddep-Befehls, ohne Python auf dem System zu installieren.
Zu den Nachteilen Änderung des Paketmanagers der Distribution auf Microdnf ist die Änderung der Struktur der internen Datenbanken und die Verarbeitung der separaten Datenbank von DNF, wodurch Sie keine Transaktionen mit in DNF erstellten Paketen in Microdnf sehen können und umgekehrt.
Pakete, die zuvor mit DNF installiert wurden, werden nach der Migration zu Microdnf als „vom Benutzer installiert aus dem DNF-Verlauf“ behandelt, und die Deinstallation eines Pakets, das von einem anderen Paketmanager installiert wurde, entfernt nicht verwendete Abhängigkeiten, die damit verbunden sind. Außerdem plant Microdnf nicht, 100 % DNF-Unterstützung auf Befehlsebene und Befehlszeilenoptionen beizubehalten.
Es wird darauf hingewiesen, dass die neue Version von Microdnf alle Hauptfunktionen von DNF unterstützen wird, aber gleichzeitig eine hohe Leistung und Kompaktheit beibehalten wird.
Wenn Sie daran interessiert sind, mehr darüber zu erfahren, können Sie sich schließlich beraten die Details im folgenden Link.
Ich bin neu in der Programmierung und begeistert von Linux. Fedora habe ich noch nie benutzt, weil ich immer ein Problem mit der Installation habe und bei Debian (und Derivaten) oder OpenSUSE lande. Aber ich glaube, ich verstehe die Bedeutung in der Linux-Welt und wie relevant das ist, was in Fedora passiert.
Mein Zweifel kommt von der Idee, C/C++ durch Python zu ersetzen, warum mit einer Low-Level-Sprache implementieren, die wegen ihrer Varianten und ihres schlecht definierten Standards stark kritisiert wurde? Ich verstehe ein wenig den Wechsel von einer interpretierten Sprache zu einer kompilierten Sprache, aber ich verstehe nicht den Sprung zu einer Sprache, bei der ich gesehen habe, dass in einigen Bereichen versucht wird, weniger zu verwenden. Wäre es nicht besser gewesen, Rust oder C# zu verwenden?
Ich kritisiere nicht die Entscheidungen der Leute von Fedora, sondern versuche zu verstehen, wie sich die Welt der Programmierung entwickelt. Ich lerne Python und JS im Web und dachte, ich würde für die Grundlagen zurück zu C/C++ springen, also scheint mir diese Notiz beim Fokussieren zu helfen.
Vielen Dank! Und wie immer hervorragende Arbeit für die Menschen in <•DesdeLinux