Suses Open Build Service ist ein leistungsfähiges Werkzeug, das nicht nur den Distributoren hilft, sondern auch dem Anwender viele taufrische Pakete beschert.
OpenSuse setzt wie keine andere Distribution auf hauseigene Werkzeuge. Das bekannteste davon kümmert sich um die Konfiguration des Systems und hört auf den Namen YaST (Abbildung 1). Es nimmt OpenSuse-Anwendern die Handarbeit beim Anpassen der entsprechenden Dateien ab. Das praktische, in Ausgabe 12/2018 in den OpenSuse-Tipps vorgestellte Backup-Werkzeug Snapper fällt ebenfalls in diese Kategorie.

Abbildung 1: Seit Urzeiten bringt (Open)Suse mit YaST ein grafisches Konfigurationswerkzeug mit, das Anwendern das Bearbeiten der entsprechenden Dateien von Hand erspart.
Für Anwender nicht direkt zu sehen sind die Hilfsmittel, die beim Bau von Paketen und der ganzen Distribution zum Einsatz kommen: Die Hauptaufgabe eines Distributors besteht im Kompilieren von Software aus dem Quellcode und dem Verpacken in handliche Pakete, die selbst Einsteiger problemlos im YaST-Modul Software installieren oder löschen einspielen.
Baumaschine
Beim Bau einer Distribution und der Pakete, aus denen sie besteht, sind Experten gefragt. Bei Suse handelt es sich dabei nicht zwangsläufig nur um fest angestellte Mitarbeiter: Zahlreiche versierte Anwender bauen auf dem OpenSuse-Build-Service [1] Pakete von neuen Versionen ihrer Lieblingsprogramme (Abbildung 2).

Abbildung 2: Die öffentlich zugängliche Webseite Open Build Service bündelt alle für den Bau von Paketen notwendigen Dateien und stößt bei jeder Änderung einen erneuten Bau an.
Diese Pakete durchlaufen automatisierte Tests [2], laden dann in der Beta-Version von OpenSuse, und gelangen schließlich auch in das neue stabile Release. Freilich leisten Suse-Entwickler immer noch einen großen Beitrag beim Aktualisieren der Distribution. Doch dank des öffentlichen Build-Services ist das Unternehmen in der Lage, die Anwender-Community besser einzubinden als andere Distributionen.
Das heißt nicht, dass der Build-Service nicht auch für weniger erfahrene Anwender interessant wäre: Er ist für jedermann zugänglich – zum Bauen von Paketen, aber eben auch, um Pakete, die andere dort erstellt haben, auf dem System zu installieren (Abbildung 3). Das gelingt mit wenigen Mausklicks und setzt keine speziellen Kenntnisse voraus.

Abbildung 3: Eine Suchmaschine gestattet es selbst Einsteigern, brandaktuelle experimentelle Pakete aus dem Build-Service mit wenigen Klicks zu installieren.
Es genügt, im Suchfeld auf https://software.opensuse.org die passende Distributionsversion zu wählen und einen Programmnamen einzugeben. Das Suchergebnis für Krita bietet neben Screenshot und Kurzbeschreibung einen Link mit dem Titel Direct Install für die bei der gewählten Distribution OpenSuse 15.1 mitgelieferte Programmversion 4.1.8 des KDE-Grafikprogramms.
Frisches Grün
Doch diese offizielle Version findet sich bereits im YaST-Modul Software installieren oder löschen. Interessant ist der Besuch der Seite erst nach einem Klick auf den etwas irreführend beschrifteten Schalter Show krita for other distibutions: Er blendet neben Paketen für andere Versionen der Distribution zusätzlich experimental packages und community packages ein, sobald Sie auf den orangefarbenen oder roten Button in der Zeile für Ihre Distributionsfassung klicken.
Bei experimentellen Paketen handelt es sich um vom OpenSuse-Team erstellte, aber noch nicht abschließend getestete Versionen. Die Community-Pakete stammen von externen Anwendern: Der Build-Service steht, wie erwähnt, nach Anmeldung [3] jedem offen. Dass der Qualitätsstandard von ungetesteten Paketen niedriger ausfällt als der von offiziellen Packages, dürfte klar sein. Pakete von Unbekannten könnten sogar Code enthalten, der Ihrem System Schaden zufügt.
Schutz davor bietet die vollständige Öffentlichkeit des Vorgangs beim Bauen der Pakete: Jeder Betrachter mit Grundkenntnissen der beteiligten Prozesse durchschaut recht leicht, aus welchen Quellen der Programmcode des Pakets stammt und wie der Service ihn, wenn überhaupt, verändert (Abbildung 2). Dazu braucht man noch nicht einmal einen Build-Service-Account.
Ganz risikofrei ist die Installation von Software aus anderen als den offiziellen Quellen also nicht. Zudem funktionieren in aller Regel, ganz anders als unter Windows, nur solche Pakete, die explizit für Ihre OpenSuse-Version bestimmt sind. Der Kasten “Warum distributionsgebundene Pakete?” erläutert, wieso das so ist.
Warum distributionsgebundene Pakete?
Windows-Programme sind oft nicht an eine Windows-Version gebunden, während Programmpakete für Linux meist nur mit einer bestimmten Version einer Distribution zusammenarbeiten. Um nicht jedes Mal das Rad neu zu erfinden, nutzen praktisch alle Programme Funktionen aus Bibliotheken. Beim Bereitstellen dieser gemeinsam genutzten Teile unterscheiden sich die Linux- und Windows-Welt grundlegend.
Windows kümmert sich nicht um das Verwalten von Third-Party-Bibliotheken. Viele Programme bringen daher eigene Varianten mit, während unter Linux dank Paketmanagement alle Programme dieselbe Version einer Bibliothek nutzen. Die Pakete sind dabei an die Versionen gebunden, für die die Entwickler sie konzipiert haben, und funktionieren daher meistens nur unter einer bestimmten Distribution. Der Vorteil liegt darin, dass bei Fehlern oder Sicherheitslücken immer nur der Austausch einer dem Paketmanagement bekannten Bibliothek nötig ist. Daher dauert das Einspielen der Updates unter Linux meist wenige Minuten, unter Windows 10 zumindest beim Einsatz von Festplatten statt SSDs etliche Stunden.
Auch unter Linux lassen sich generische ausführbare Dateien erstellen, die nicht an eine Distribution gebunden sind, wie etwa die von Mozilla herausgegebene Firefox-Fassung demonstriert. Einen neueren Ansatz für distributionsübergreifend lauffähige Pakete stellt das Appimage-Format [3] dar, das außer der eigentlichen Programmdatei alle Abhängigkeiten einpackt, die nicht auf allen Linux-Systemen zwingend vorhanden sind. Das macht AppImages ähnlich universell wie viele Windows-Executables, doch bei Updates ähnlich unbeholfen.
Abbildung 3 zeigt das Ergebnis der Suche für das Grafikprogramm Krita nach Ausklappen der Community- und experimentellen Pakete. Während die official release für Leap 15.1 die Versionsnummer 4.1.8 aufweist, lag beim Verfassen der OpenSuse-Tipps eine orangefarben gekennzeichnete experimentelle Version 4.2.7 vor. Dieses Paket diente im Test als Beispiel.
Um es einzurichten, genügt ein Klick auf die grüne Schaltfläche 1 Click Install. Firefox öffnet in der Voreinstellung direkt die YaST 1-Klick Installation. Sie fügt den Paketquellen zunächst das Repository mit dem experimentellen Paket hinzu (Abbildung 4), und zusätzlich, um sicherzustellen, dass die Installation auf dem aktuellen Stand ist, das offizielle OpenSuse-Update-Repository.

Abbildung 4: Der 1-Click-Wizard, den Sie über einen Klick auf die grüne Schaltfläche der Software-Suchmaschine starten, bindet vollautomatisch die nötigen Software-Repositories des Build-Services ein.
Sicher?
Die mit download.opensuse.org beginnenden URLs legen nahe, dass die Repositories tatsächlich auf dem OpenSuse-Build-Service liegen. Abbildung 4 zeigt den ersten Screen des 1-Click-Wizards, der über die zusätzlichen Repositories informiert. Normalerweise ist es nicht erforderlich, diese Vorauswahl zu verändern.
Der nächste Schritt fragt nach den Software-Komponenten, die Sie installieren wollen; im Beispiel handelt es sich nur um das Programm Krita. YaST zeigt nun zur Kontrolle ID und Fingerabdrücke des Schlüssels der hinzuzufügenden Repositories, denen Sie vertrauen sollten – am besten aber erst nach einem Check von ID und Fingerabdruck auf der Webseite des Build-Services.
Dazu klicken Sie im Suchergebnis (Abbildung 3) auf den grünen Link zum Repository KDE:Extra. Sie landen dann zunächst auf der Unterseite des Repositorys zum Paket Krita, müssen also im Pfad links oben noch eine Ebene zu KDE:Extra zurückgehen. Dort zeigt ein Klick auf GPG Key / SSL Certificate die Werte für ID und Fingerprint des Repository-Schlüssels (Abbildung 5).

Abbildung 5: Der 1-Click-Wizard listet den kryptografischen Schlüssel des Build-Service-Repositorys, den Sie mit der Build-Service-Webseite vergleichen sollten.
Stimmen beide mit den Werten in YaST überein und erscheint zusätzlich das Schloss-Symbol in der Adressleiste des Browsers grün, dann sind Sie kryptografisch gegen Angriffe beim Übertragen der Pakete geschützt. Nach dem Vertrauen aller Repositories läuft die Installation ohne weitere Zwischenfragen durch.
Es besteht wenig Gefahr, Ihr Gesamtsystem durch die Installation einer experimentellen Version eines einzelnen Programms zu ruinieren. Allerdings installiert der Wizard bei Bedarf neue Versionen von Bibliotheken. Im Fall von Krita bindet er etwa das experimentelle Repository KDE:Extra mit ein. Das kann im schlimmsten Fall Ihre Desktop-Umgebung zum Absturz bringen. Es erscheint also ratsam, sich vorher zu informieren, wie Sie notfalls Ihr System mit Snapper auf einen stabilen Zustand zurückdrehen [4].
Eigenbau
Zu erläutern, wie Sie ohne Vorlage eigene Programmpakete bauen, würde für die OpenSuse-Tipps zu weit führen. Doch mithilfe des Build-Services gelingt es oft auch ganz leicht, ein Paket aus dem viel öfter aktualisierten OpenSuse Tumbleweed auf OpenSuse Leap 15.1 zu portieren. Besorgen Sie sich dazu zuerst einen Build-Service-Account [5], und loggen Sie sich ein. Suchen Sie dann auf https://software.opensuse.org nach dem Programm, das Sie auf eine neue Version heben möchten.
Als Beispiel dient in diesem Beitrag Inkscape. Das Programm lag beim Schreiben des Artikels für OpenSuse Tumbleweed in Version 0.92.4 vor, in Leap 15.1 dagegen erst in Version 0.92.2 – ein eher unbedeutendes Update, doch es geht um das auf andere Pakete übertragbare Vorgehen.
Klappen Sie mit einem Klick auf Show Inkscape for other Distributions die Liste aller Distributionsvarianten aus, und folgen Sie dem grünen Link official release in der Sparte openSUSE Tumbleweed. Das öffnet die zugehörige Build-Service-Seite (Abbildung 6). Eingeloggte Anwender sehen links unter dem grünen Titel den Link Branch package. Ein Klick darauf kopiert das Build-Service-Projekt in ihr Build-Service-Home.

Abbildung 6: Der Build-Service kopiert mit einem Klick die Quelldateien existierender Pakete in Ihren persönlichen Bereich.
Um sich nicht unnötig mit Unterprojekten im Build-Service-Account zu belasten, klappen Sie den Pfeil vor More options aus und kürzen den Branch project name auf home:Benutzer. Dann finden Sie die Kopie des Pakets direkt in Ihrem Home Project (Link oben rechts).
Unter Packages ist dort nun Inkscape zu sehen. Öffnen Sie zunächst den Reiter Repositories. Aktivieren Sie dort nach einem Klick aufAdd from a Distribution das Kontrollkästchen openSUSE Leap 15.1 (Abbildung 7) um das Build-Ziel OpenSuse Leap 15.1 hinzuzufügen – sprich: das Paket für diese Distributionsversion zu bauen.

Abbildung 7: Mit dem Open-Build-Service bauen Sie Pakete für die verschiedensten Distributionen. Als Beispiel dient die stabile Leap-Version 15.1; der Bau von Paketen für Debian oder Arch Linux funktioniert ganz anders.
Scrollen Sie dann die Seite herunter bis zum Kasten Repositories Flags. Nun klicken Sie in der Tabelle Publish Flag auf das linke obere Verbotssymbol, das sich daraufhin in einen grünen Haken verwandelt. Das Publish Flag bewirkt, dass der Build-Service für erfolgreich gebaute Pakete ein Repository bereitstellt, das Sie bei Bedarf ins eigene System einbinden.
Folgen Sie, wieder im Reiter Overview, dem blauen Link zum Paket Inkscape. Nach einer Weile – wie lang es dauert, hängt von der Last auf den Build-Service ab – erscheint in der Spalte Build Results der Status building: 1. Mit etwas Glück (wieder je nach Last) sehen Sie vielleicht zehn Minuten oder eine halbe Stunde später den Status succeeded: 1 (Abbildung 8). Das setzt voraus, dass Sie die Seite neu laden oder auf Refresh klicken.

Abbildung 8: Hier hat der Bau des von Tumbleweed übernommenen Inkscape-Pakets für Leap 15.1 geklappt.
Einen Versuch wert
Statt suceeded erscheint unter Umständen die Statusmeldung failed. Es gibt etliche Gründe, warum ein Paket mit der neueren Software-Version beim Bau für eine ältere OpenSuse-Ausgabe Probleme bereitet. Oft sind die dort enthaltenen Bibliotheken nicht aktuell genug, die Liste der Möglichkeiten fällt aber wesentlich länger aus. Da das Portieren einer neuen Paketversion auf eine ältere Distribution meist wenig Mühe bereitet, lohnt sich der Versuch jedoch in jedem Fall.
Hat der Bau des Pakets geklappt, folgen Sie dem Link hinter dem Repository-Namen openSUSE_Leap_15.1 oberhalb der Statusmeldung. Sie gelangen zu einer Liste aller gebauten Pakete (Abbildung 9), die Sie theoretisch einzeln herunterladen könnten. Der bessere Weg zum Einrichten der Software besteht darin, das entsprechende Repository in YaST einzubinden.

Abbildung 9: In der Übersicht für die Ergebnisse des Paketbaus findet sich ein Link für ein YaST-Repository zum Einbinden ins System.
Die URL des Links Go to download repository oberhalb der Liste der Pakete nennen Sie dem YaST-Modul Software-Repositories nach einem Klick auf Hinzufügen. Behalten Sie die Standardeinstellung URL angeben bei, und fügen Sie die Adresse aus dem Browser ein. Geben Sie dem Repository einen aussagekräftigen Namen. In dem Repo findet sich das von Ihnen gebaute Inkscape-Paket, und Sie installieren es sauber über das Paketmanagement (Abbildung 10). Sollten Sie weitere Pakete im Home-Projekt Ihres Build-Service-Accounts bauen, stehen diese auf dieselbe Weise bereit.

Abbildung 10: Das in YaST eingebundene Build-Service-Repository Pkreussel enthält die aufgefrischte Version 0.92.4 von Inkscape.
Manchmal genügt das Ändern weniger Zeilen in einer Textdatei, um ein bestehendes Paket auf eine neue Version der Software zu aktualisieren. Erzeugen Sie dazu wie beschrieben einen Branch eines bestehenden Pakets im Home des Build-Service-Accounts. Stellen Sie dann auf der Homepage des zugehörigen Programms die aktuelle Version fest.
Folgen Sie wieder dem Link hinter dem Namen des geklonten Pakets im Home-Projekt. In unserem Beispiel handelt es sich dabei um das Grafikprogramm Hugin. Als Erstes fügen Sie den Quellcode der neuen Fassung hinzu. Abbildung 11 zeigt den Download-Bereich des Programms auf Sourceforge: Die neueste Versionsnummer lautet 2019.0.0, die Datei mit der Endung tar.bz2 enthält deren Quellcode. Bei den anderen beiden Dateien handelt es sich um Installer für Windows und Mac OS X.

Abbildung 11: Bei Open-Source-Programmen, wie hier der Bildbearbeitung Hugin, gelangen Sie im Allgemeinen leicht an den aktuellen Quellcode – im konkreten Fall beispielsweise auf Sourceforge.
Im geklonten Paket ist der Quellcode für die Vorgängerversion 2018.0.0 zu sehen. Die aktuellen Sourcen fügen Sie durch einen Klick auf add file hinzu. Im sich öffnenden Dialog geben Sie in das Feld File URL die per Rechtsklick im Browser ermittelte Download-Adresse ein und klicken auf Save. In der Dateiliste im Build-Service erscheint zunächst nur eine kleine Datei mit dem Namen _service, die aber den automatischen Download vor dem Paketbau veranlasst.
Um wirklich die aktuelle Version zu bauen, editieren Sie noch die Datei Programm.spec in der Dateiliste. Bei der Spec-Datei handelt es sich um die zentrale Steuerdatei für den Bau des Pakets. Im Build-Service öffnet ein Klick auf den Dateinamen einen Editor. Suchen Sie dort die mit Version: beginnende Zeile und ändern Sie die Versionsnummer in 2019.0.0.
Bei Hugin müssen Sie zusätzlich die Variable mversion in der Zeile darüber auf 2019.0 setzen, denn diese Zeichenkette mit einer Null weniger ist nötig, um den Download-Pfad auf Sourceforge zu erzeugen (Source: einige Zeilen tiefer).
Oft, aber nicht immer genügt das Ändern des Werts in der Zeile Version:; generelle Regeln gibt es dafür aber nicht. Darüber hinaus ist keineswegs garantiert, dass der Prozess nach dem Erhöhen der Versionsnummer erfolgreich durchläuft. Sie finden das heraus, indem Sie auf der Editor-Seite nach unten scrollen, die Änderungen der Spec-Datei mit Save speichern, und oben links auf der Seite wieder zu Projects | home:Benutzername | hugin wechseln. Dann heißt es, beim Build Result wieder auf succeeded oder failed zu warten.
Fazit
Der Open Build Service ist eigentlich als Werkzeug für Entwickler gedacht, nicht als Tool für Endanwender. Hier finden sich jedoch die aktuellsten Pakete für OpenSuse (und andere Distributionen). Das frei zugängliche Web-Portal erleichtert erste Ausflüge in das endlose Thema Paketbau.
Glossar
-
Kompilieren
-
Vorgang, bei dem eine entsprechende Software (der Compiler) den Quellcode in Maschinencode übersetzt.
Infos
-
OpenSuse-Build-Service: https://build.opensuse.org
-
OpenQA: http://open.qa
-
Appimage: https://appimage.org
-
Snapper System Rollback: https://de.opensuse.org/openSUSE:Snapper_Tutorial
-
Build-Service-Account beantragen: https://www.microfocus.com/selfreg/jsp/createOpenSuseAccount.jsp





