Mit Fedora 22 setzt Red Hats Community-Ableger zum ersten Mal auf den Paketverwalter DNF als Standard. Wir zeigen, was Sie beim Umstieg beachten müssen.

RPM gehört zu den Urgesteinen der Paketmanagement-Gattung. Damit lassen sich Pakete bauen, installieren, aktualisieren oder auch wieder sauber aus dem System löschen – doch damit enden die Fähigkeiten. Geht es um das automatische Auflösen von Abhängigkeiten, das Verwalten externer Paketquellen oder ausgeklügelte Suchfunktionen, muss RPM passen. Zwar bietet bereits die Version 5 von RPM die Möglichkeit [1], ansatzweise ohne Zusatzwerkzeuge auszukommen, doch sie entstand aufgrund eines Entwicklerstreits. Weder Red Hat noch Fedora unterstützen sie, die Funktionen kommen nur in Fedora-inkompatiblen Distributionen wie OpenMandriva oder PLD zum Einsatz.

Lange Zeit übernahm das von Yellow Dog Linux übernommene Yum die anspruchsvolleren Aufgaben; Fedora 22 macht damit nun aber Schluss und klärt die Fronten: Das schon in Fedora 18 erstmals erschienene DNF [2] löst das bisher als Standardwerkzeug zum Einsatz kommende Yum ab. Die vor vier Jahren veröffentlichte Version 3.4.3 von Yum steht jedoch weiterhin in den Fedora-Paketquellen. Die Fedora-Entwickler pflegen zudem noch etwa acht Jahre anfallende Bugfixes ein, bis zum virtuellen Ableben von Red Hat Enterprise Linux 7 und dessen Derivaten. Eine echte Weiterentwicklung aber findet nicht mehr statt.

Der Hauptgrund für den Wechsel waren nicht nörgelnde Benutzer, sondern die Yum-Entwickler, die ihrem Produkt keine große Zukunft mehr bescheinigen. Spätestens seit feststand, dass Fedora schon lange vor dem vorbestimmten Tod von Python 2 in fünf Jahren auf die Version 3 der Skriptsprache als Standard setzen würde, war das Ende von Yum abzusehen: Niemand wollte die Portierung in die Hand nehmen.

Letztendlich war dies jedoch nur der Auslöser, aber nicht die einzige Ursache. Für den Nachfolger war das Auslagern der Abhängigkeitsauflösung in eine eigene Bibliothek angedacht, die auch von Mitbewerbern wie Pacman oder Apt genutzt werden kann oder zumindest könnte. Mit dem libsatsolver findet sich auch eine entsprechende Umsetzung. Die Yum-API war ebenso fehlerbehaftet wie dokumentationsarm und schwer zu pflegen.

Mit all diesen sperrigen Unzulänglichkeiten soll DNF nun aufräumen: Es steht von Anfang an bilingual für Python 2 und 3 zur Verfügung. Obendrein bringt es eine strikte, gut dokumentierte API mit, die mit der heißen Nadel gestrickte Hacks von vornherein unnötig macht.

Für Benutzer

Geht es nur um gewöhnliche Aktionen wie das Installieren, Aktualisieren oder Löschen von Paketen, müssen sich gewöhnliche Fedoraner wenig kümmern. Wie steht es jedoch mit der Umgewöhnung für all jene, die Yum nicht erst seit gestern kennen und regelmäßig nutzen?

Zunächst gilt es zu loben, dass DNF neben der grundlegenden RPM-Datenbank auf die Yum-Daten zugreift und keine weitere inkompatible Datenbank erfordert. Diese hätte die Migration und Distributionsaktualisierung bestehender Systeme wesentlich erschwert, wenn nicht gar unmöglich gemacht. Im kommerziellen Umfeld wäre dies ein Ding der Unmöglichkeit.

Als alter Bekannter blieb der Warnhinweis, der bei zwischenzeitlichen Änderungen an der RPM-Datenbank direkt mit dem rpm-Befehl beim nächsten Aufruf von DNF erscheint. Dieses Vorgehen mag DNF genauso wenig wie Yum, aber nur in wenigen Fällen bringt ein solcher Fehltritt das System wirklich aus dem Gleichgewicht. Somit bleibt auf lange Sicht gewährleistet, dass sich theoretisch beide Befehle unabhängig voneinander zur Systempflege eignen. Dies macht besonders dann Sinn, wenn man Yum-Plugins braucht, für die es noch kein entsprechendes DNF-Pendant gibt.

Eine radikale Umgewöhnung steht für viele Aufgaben gar nicht an. Wie Yum bietet auch DNF zahlreiche Unterbefehle für klar umrissene Aufgabengebiete, die ohne das GNU-typische Doppelminus auskommen. Ein dnf install Paket sucht nach dem gewünschten Paket und installiert es. Die Aktualisierung eines vorhandenen Pakets besorgt dnf update Paket. Lassen Sie den Paketnamen weg, bringt DNF das ganze System auf den neuesten Stand.

Als neue Funktion entfernt DNF mit dnf remove Paket (aus Gründen der Abwärtskompatibilität funktioniert auch dnf erase) nicht nur die ausgewählten Pakete, sondern im selben Zug auch die danach nicht mehr benötigten Abhängigkeiten – das entspricht in etwa dem Zurückrollen einer Transaktion in Yum. Sollen die abhängigen Pakete erhalten bleiben, müssen Sie zu Rpm greifen. Der Flächenbrand bei der Deinstallation eines Pakets lässt sich nur durch Deaktivieren von clean_requirements_on_remove in der DNF-Konfiguration verhindern. Andererseits hilft das Programm so, Platz und Bandbreite für zukünftige Aktualisierungen zu sparen, indem Paketleichen gar nicht erst entstehen.

Ein Beispiel zeigt die Terminalausgabe von dnf update in Abbildung 1. Hier lassen sich keine gravierenden Änderungen gegenüber Yum wahrnehmen. Die Kernel-Pakete verdienen jedoch besonderes Augenmerk: War der Betriebssystemkern früher beinahe unantastbar, so führt DNF nun ohne Murren ein dnf remove kernel aus und entfernt sämtliche Pakete mit diesem Namensteil. Ohne Kernel kein Linux – somit legen Sie Ihr System dauerhaft lahm. Zwar lässt sich so eine Aktion reparieren; fraglich bleibt jedoch, warum die Entwickler keinen Grund mehr sehen, solch gefährliche Aktionen zu verhindern, wie das noch in Yum der Fall war. Um ein Kernel-Paket zu löschen, war dort noch die explizite Versionsangabe erforderlich.

Abbildung 1: Wie gehabt: die DNF-Ausgabe beim Einspielen von Aktualisierungen unter Fedora 22.

In der Tabelle “Alt gegen neu” finden Sie einen direkten Vergleich einiger früherer Yum-Befehle mit den entsprechenden DNF-Pendants. Die Tabelle erhebt keinen Anspruch auf Vollständigkeit, wobei es zu bedenken gilt, dass sich manche fehlenden Funktionen auch per Skript nachbilden lassen. Gelegentlich hilft auch ein Blick in die DNF-Konfiguration.

Möchten Sie unter Fedora ein heruntergeladenes oder manuell aus dem Quellcode erstelltes Paket installieren, mussten Sie Yum das Kommando localinstall und gegebenenfalls noch --nogpgcheck mit auf den Weg geben. DNF genügt hingegen die Angabe eines Dateinamens, alternativ auch einer URL, sodass separates Herunterladen entfällt. Ein typischer Anwendungsfall dafür wäre zum Beispiel das Aktivieren der RPM-Fusion-Quelle, in der aus Fedora-Sicht in einer rechtlichen oder lizenztechnischen Grauzone angesiedelten Pakete lagern, ohne die aber insbesondere multimedial interessierte Benutzer kaum auskommen.

Plugins

Yum war stets für zahlreiche Plugins bekannt, die den Paketmanager um weitere Funktionen ergänzen. Obwohl sich DNF auch durch einen Yum-Alias aufrufen lässt, sind diese Plugins zu DNF nicht kompatibel. Halb so schlimm: Ein Großteil der Plugin-Funktionen hat die Portierung bereits hinter sich. Frühere externe Funktionen fanden teils direkt in DNF ihren Platz, teils lagerten die Entwickler diese in die zusätzlichen Pakete dnf-plugins-core und dnf-plugins-extras aus.

Das Paket dnf-plugins-core enthält, wie der Name schon andeutet, grundlegende Plugins. Dazu gehören debuginfo-install zum Einspielen der Programmquellen zur Fehlersuche bei Abstürzen oder copr zum Einbinden inoffizieller Quellen, denen aber innerhalb der Fedora-Gemeinschaft die Paketbau-Server und weitere Teile der Infrastruktur zur Verfügung stehen. Copr ähnelt den aus der Ubuntu-Welt bekannten PPAs. Ein ausgeglichenes Maß aus Vorsicht und Courage vorausgesetzt, können Sie damit den ohnehin aktuellen Fedora-Paketpool noch aktueller halten. Auf diese Weise kommt Fedora einer echten Rolling-Release-Distribution ein ganzes Stück näher.

Darüber hinaus schafften auch ausgefallene Yum-Erweiterungen den Sprung in die DNF-Kompatibilität: So erstellt zum Beispiel repograph aus den installierten Paketen einen grafischen Abhängigkeitsbaum gigantischen Ausmaßes im Dot-Format. Bei Problemen mit Abhängigkeiten sucht repoclosure nach unaufgelösten Abhängigkeiten in lokalen oder entfernten Paketquellen. Noch immer harren etliche andere Erweiterungen der Portierung, was ein interessantes Betätigungsfeld für Python-affine Programmierer wäre, die zur Verbesserung und Vervollständigung von DNF beitragen wollen.

Die Tabelle “Portierte Plugins” listet die von Yum übernommenen Plugins auf und zeigt sowohl den entsprechenden Befehl an als auch das Paket, aus dem es stammt. In den meisten Fällen stammen die Erweiterungen aus den beiden genannten und von den DNF-Entwicklern betreuten Plugin-Paketen, die zur Standardinstallation zählen.

Lieber mit GUI?

In vielen Fällen merken Benutzer gar nichts davon, dass hinter den Kulissen ein Machtwechsel vor sich ging. Wer nur mit grafischen Werkzeugen zur Paketverwaltung arbeitet, wird sanft migriert. Die meisten grafischen Paketverwaltungswerkzeuge setzen weder auf Yum noch auf DNF auf, sondern nutzen PackageKit [4] als Zwischenschicht. Das erleichtert den Entwicklern durch eine einheitliche und distributionsübergreifend funktionierende API oberhalb von Kommandozeilen-Tools wie Yum, DNF oder Apt und Pacman die Arbeit. Als einziger grafischer Paketmanager kommt das aus dem ursprünglichen Yum-Frontend entstandene Yumex-DNF [5] ohne PackageKit aus. Das GTK3-basierte Programm passt sich optisch und bedientechnisch gut in Gnome ein, lässt sich aber auch unter anderen Benutzeroberflächen verwenden.

Gegenüber dem alten Yumex bietet Yumex-DNF hinsichtlich seiner Funktionalität wenig Neues. Beim Start des Programms ruft das Programm im Hauptfenster (Abbildung 2) die neuesten Paketversionen ab und zeigt sie in der Übersicht an. Beim Klick auf eines der Pakete erscheinen im unteren Fensterteil weitere Informationen zum ausgewählten Eintrag. Über das Plus-Symbol in der Kopfzeile der Paketliste wählen Sie die gefundenen Pakete aus und führen mit dem Zahnrad-Knopf oberhalb der Liste übliche Aktionen wie Installieren, Aktualisieren oder Löschen aus. Praktischerweise fragt Yumex-DNF erst beim Ausführen einer Aktion nach dem Root-Passwort, was das Programm auch für gewöhnliche Benutzer für das Durchsuchen der Paketquellen und der lokalen Paketdatenbank interessant macht.

Abbildung 2: Alter Bekannter im neuen Gewand: Yumex-DNF hält die Fahne des direkten Zugriffs auf DNF hoch, ohne PackageKit zu benötigen.

Ansonsten kommt DNF über das PackageKit-Backend mit jeder darauf basierenden Paketverwaltungssoftware zurecht. In der neuesten Distributionsversion ersetzt DNF in der PackageKit-Konfiguration Yum und versieht seither dort seinen Dienst. Hier könnten Sie wieder händisch eingreifen und auf Yum ausweichen, aber die grafischen Programme würden davon kaum profitieren. Wie so oft gilt auch hier, dass grafische Frontends den ihnen zugrunde liegenden Befehlszeilenprogrammen funktionell mehr oder weniger hinterherhinken. Etwas Einarbeitung vorausgesetzt, kommen Sie mit dem puren DNF genauso komfortabel und oft schneller ans Ziel.

Ausblick

In DNF steckt noch viel Potenzial, insbesondere im Hinblick auf einige exotische Yum-Plugins, die noch nicht den Weg in die schöne neue Welt gefunden haben. Auch die zukunftssichere Python-3-fähige Basis und die problemlose Migration der Yum-Datenbank sprechen für sich.

In der Vergangenheit geriet Fedora schon öfter in Verruf, weil es kompromisslos technologisch vorpreschte, obwohl es Alternativen gegeben hätte. Ein typisches Beispiel aus den letzten Jahren war die halbherzige Einführung von Systemd in Fedora 15, die so manchem Administrator den Schweiß auf die Stirn trieb: Lange nicht alle relevanten Pakete waren bereits auf Systemd migriert, im Ernstfall musste man sich gleich mit zwei Init-Systemen herumschlagen. Die Ankündigung eines neuen Standardwerkzeugs sorgte auch im Fall von DNF wieder für Unmut bei altgedienten Benutzern, deren Lamentieren verstummte jedoch recht schnell. Freilich müssen Sie als Anwender ein wenig umlernen, das grundlegende Verhalten hat sich jedoch nicht wesentlich geändert.

Gespannt darf man auch darauf sein, wie sich DNF auf zukünftige Systemaktualisierungen auswirkt. Der Sprung von einer Distributionsversion zur nächsten war bei Fedora oft ein Glücksspiel. Schon kleinste Problemchen brachten das frühere Preupgrade und später Fedup gehörig aus dem Tritt. Entweder endete die Aktion in einem Neuaufsetzen des Systems, oder man griff doch lieber auf das nicht offiziell unterstützte, aber genügsamere Skript fedora-upgrade [6] zurück, das ohne viel Schnickschnack allein mit Yum das System auf den neuesten Stand brachte. Sollte es dank des offensichtlich fehlertoleranteren DNF gelingen, den Anteil zufriedener Nutzer nach einem Upgrade mit Fedup zu erhöhen, dann wäre viel gewonnen und Fedora um einen schlechten Ruf ärmer.

Die Vor- und Nachteile von DNF und Yum gegeneinander abzuwägen, um eine Empfehlung auszusprechen, wäre hier fehl am Platz. Wie man es auch dreht und wendet: Ihnen bleibt sowieso nichts anderes übrig, als umzusteigen. Yum steht bis auf Weiteres noch in den Paketquellen zur Verfügung, aber allein das biblische Alter dessen neuester Programmversion und die schlechten Aussichten auf weitere Pflege sollten Sie dazu bewegen, DNF eine faire Chance zu geben. Wer Fedora 22 neu installiert, wird ohnehin nicht mehr ohne händische Nachinstallation mit Yum in Berührung kommen.