Vor kurzem wurde Fedora 27 Server veröffentlicht. Eigentlich sollte dieses Release im Rahmen des Boltron-Projekts modular aufgebaut sein. Veröffentlicht wurde jedoch eine herkömmliche Server-Edition. Die Entwickler verwarfen den ursprünglichen Ansatz, den sie vor über einem Jahr formuliert hatten und schicken das Projekt »modularer Server« wieder zurück aufs Reißbrett. Red Hats Stephen Gallagher hat jetzt die technischen Hintergründe der ursprünglichen und der überarbeiteten Version näher erläutert.
Nicht alles gelingt auf Anhieb
Fedoras Modularity-Initiative zielt darauf ab, es den Paketierern zu erleichtern, alternative Versionen von Software zu erstellen, und Benutzern die Möglichkeit zu geben, diese sogenannten Streams unkompliziert zu benutzen. Daran arbeitet Fedora bereits seit mehreren Jahren, im Sommer dieses Jahres wurde dann der Boltron-Prototyp und später eine Beta-Version zum modularen Server für Fedora 27 ausgeliefert. Die Rückmeldungen zeigten aber, dass diese Testversionen das gesetzte Ziel nicht erreichten und ein Umdenken erfordern.
In erster Linie wurde für den Neubeginn die Idee einer streng gepflegten, stabilen Wurzel aufgegeben. Herkömmliche Fedora-Builds werden ausgeführt, indem ein RPM in einem Buildroot erstellt wird, das die neuesten Pakete enthält, die im Stable-Updates-Repository für eine Veröffentlichung verfügbar sind. Mit Modularität hoffte Fedora, eine kleine und spezifische Buildroot definieren zu können, die stabil und für die gesamte Lebensdauer einer Veröffentlichung erhalten bleiben würde. Darauf sollten die einzelnen Module aufbauen.
Haupt-Repository als Plattformmodul
Das stellte sich im Verlauf der Entwicklung als nicht praktikabel heraus. Es hätte erfordert, einen Punkt zu finden, an dem die gesamte Buildroot verwendet werden konnte, um sich selbst zu bauen. Dieses Ziel wurde nicht erreicht. Stattdessen wurde entschieden, Fedoras Haupt-Repository als Plattformmodul zu behandeln. Praktisch bedeutet dies, dass die Entwickler von Modulen nicht mehr einen schwierigen Prozess durchlaufen müssen, um herauszufinden, welche Module eine Abhängigkeit bieten, die sie benötigen. Stattdessen können sie sich auf die Systemversion verlassen, die im Haupt-Repo verfügbar ist.
Problemlose Umstellung
Dies ermöglicht einen einfachen Upgrade-Pfad, da die traditionellen Repositories sowie eine Reihe von Standardmodulen beibehalten werden. Das bedeutet, dass ein Upgrade von einem aktuellen Fedora 27-System auf ein modulares Fedora 28-System ohne besondere Schritte möglich sein wird. Tatsächlich bedeutet dieser Ansatz auch, dass die Modularität nicht auf die Server-Edition beschränkt bleiben muss, sondern auch für die Workstation-Edition gelten kann.
Um den Vorgang zu vereinfachen sollen Werkzeuge zur Verfügung gestellt werden, um die Erstellung der Module zu automatisieren. Selbst für komplexere Multipackage-Module bieten die automatisch erstellten Module einen einfachen Ausgangspunkt.
Zwei Repository-Sets
Aus der Sicht des Endbenutzers wird Fedora mit zwei Sets von Repositories ausgeliefert. Zum einen die traditionellen Fedora-Repositories (Fedora, Updates und Update-Tests) und zum anderen ein neuer Satz von Repositories mit alternativen und ergänzenden Modulen. Die Bezeichnungen dieser Repositories sind noch nicht endgültig.
Mit diesem Design kann jeder, der nicht auf die zusätzlichen Versionen der von Modulen bereitgestellten Software zugreifen möchte, die modularen und modularen Update-Repositories deaktivieren, und sein System wird genau so funktionieren, wie es heute funktioniert. Pakete, die mit Fedoras traditionellem Prozess erstellt wurden, werden aus dem regulären Fedora-Repository installiert und verwaltet, ebenso wie Standardversionen von Paketen, die den neuen Prozess hinter den Kulissen verwenden.
Standard oder modular
Für alle, die Zugriff auf zusätzliche Versionen von Paketen haben möchten, werden diese neuen Modul-Repositories diese zur Verfügung stellen. Benutzer können mit diesen neuen Repositories interagieren, indem sie die Vorteile einer neuen Syntax in DNF nutzen, wie sie auch in der Modular Server Beta verwendet wurde. Wenn ein Benutzer einen bestimmten Modul-Stream installieren möchte, kann er den neuen Befehl dnf install module foo/bar benutzen.
Dieser überarbeitete Plan bietet eine verständliche und darstellbare Zukunft für Modularität. Paketierer, die keine Module erstellen wollen, können weiterhin genau so packen, wie sie es immer getan haben, ohne ihre Arbeitsabläufe zu verändern. Diejenigen, die alternative Versionen von Software in einer einzigen Version oder dieselbe Version über mehrere Versionen hinweg bereitstellen wollen, werden neue Werkzeuge erhalten, um dies zu vereinfachen. Da die Anzahl der verfügbaren Module wächst, werden die Benutzer von Fedora einen viel einfacheren Zugang zu der genauen Version der Software haben, die sie für ihre Aufgaben benötigen.
Schreibe einen Kommentar