Build Service/Anleitung

aus openSUSE, der freien Wissensdatenbank

Dieses Dokument soll einen Überblick über den Build Service bieten und als Anleitung dienen, wie Sie mit diesem großartigen Werkzeug Pakete für verschiedene Distributionen bauen. Wir werden versuchen, alle Aktionen anhand einer Beispielanwendung zu zeigen, so dass Sie die einzelnen Schritte verfolgen können, um ihre eigenen Pakete zu bauen.

Grundvoraussetzungen

Sie sollten über ein allgemeines Verständnis im Bau von RPMs oder über Erfahrung im Umgang mit anderen Paketsystemen wie dpkg verfügen. Dieses Dokument ersetzt nicht die Paketbaudokumentation, mit welcher sich schon viele andere Anleitungen, Führer und Bücher beschäftigen.

Sie sollten Sich mit der Quellkodeumgebung auskennen, welche ihr Projekt für ihr Paket verwendet. Der Build Service kann einige verbreitete Fehler umschiffen und wird Sie hoffentlich auf einige Probleme in ihrem Quellkode via Protokolldateien und mit einfachen Baufehlern hinweisen. Es existiert eine Build-Service-Mailing-Liste , die ihnen als Quelle für Hilfe und Unterstützung dienen kann. Nichtsdestotrotz liegen die Entscheidungen darüber, welche Patches Sie anwenden wollen, welche Compiler-Flags Sie setzen wollen usw. bei ihnen.

Voraussetzungen

Um Gebrauch vom Build Service zu machen, benötigen Sie als erstes ein Nutzerkonto um sich anzumelden. ;-)

Ihr Benutzerkonto für den Build Service ist das selbe, welches Sie auch für das Wiki und Bugzilla verwenden. Wenn Sie noch über kein Konto verfügen, nutzen Sie einfach die Verknüpfung oben rechts auf dieser Seite um eins zu erstellen.

Nachdem Sie ihr Konto erstellt haben gehen Sie auf http://build.opensuse.org/ und melden sich dort an. Bei der ersten Anmeldung müssen Sie ein Anforderungsformular ausfüllen und erklären, warum Sie ein Benutzerkonto möchten und was Sie paketieren wollen. Danach müssen Sie nur noch warten bis ihr Konto freigeschaltet wird. Während Sie warten, können Sie sich schon auf der opensuse-buildservice-Mailing-Liste einschreiben und sich dort vorstellen. Erzählen Sie uns dort ihren Namen und etwas über das Projekt, welches Sie erstellen und betreuen wollen (einige Worte zu ihren Paketbaufähigkeiten sind auch immer willkommen).

Wenn Sie ihre Pakete zu Hause testen und/oder bauen wollen (immer eine gute Idee!) sollten Sie einen Blick auf das SUSE Build Tutorial werfen, um einen Überblick zu erhalten, was Sie für eine lokale Bauumgebung benötigen.

Terminologie

Der Build Service beherbergt Projekte/projects (Sie können eine Liste davon anschauen (benötigt eine Anmeldung)). Jedes Projekt enthält die Ressourcen, um ein oder mehrere Pakete/packages (bspw. RPMs) zu bauen. Diese Ressourcen umfassen Quellcodearchive, patch-Dateien, spec-Dateien, usw. Die Ergebnisse eines Projekts landen in einem oder mehreren Paketdepots/repositories. Ein Paketdepot ist ein altbekanntes Konzept: einfach ein Haufen Pakete, organisiert in einer Verzeichnishierarchie, zusammen mit einigen Index-/Metadaten-Dateien, die es Werkzeugen wie zypper erleichtern, die Pakete zu durchsuchen und Abhängigkeiten aufzulösen. Die Paketdepots, in denen ein Projekt seine Ergebnisse veröffentlicht, korrespondieren mit den verschiedenen Betriebssystemversionen, wie openSUSE 10.3 usw.

Neben den "normalen" Projekten gibt es "offizielle" openSUSE-Projekte, die die in den Standard-openSUSE-Distributionen angebotenen RPMs bauen. Das Projekt "factory" ist das in Arbeit befindliche Projekt, aus dem die nächste openSUSE-Distribution entstehen wird. Es gibt außerdem noch viele bereichsspezifische Projekte wie Apache und network:telephony. Schlussendlich erhält jeder Nutzer sein eigenes "Spielwiesenprojekt" namens home:Benutzername.

RPMs tendieren dazu, einen Haufen Abhängigkeiten zu anderen RPMs zu haben, und oftmals stammen diese RPMs aus verschiedenen Projekten im Build Service. tend to have lots of dependencies on other RPMs, and often these RPMs come from different projects within the Build Service. Das hat zwei wichtige Folgen.

Erstens: Wenn ihr Paket zur Laufzeit von anderen Paketen abhängt ("Requires"), dann wird es oftmals auch zur Bauzeit davon abhängen (bspw. "Build-Requires"). Der Build Service sucht und findet nicht automatisch Abhängigkeiten für Sie (die nicht in der Standarddistribution enthalten sind, für die Sie bauen). Sie müssem dem Build Service also irgendwie mitteilen, wo er die nötigen Pakete finden kann.

Zweitens: Es ist ein schönes Zeil für ein Paketdepot, transitiv geschlossen zu sein, bspw. indem jede Abhängigkeit von jedem Paket im Depot auch von Paketen aus dem Depot erfüllt wird (ausgenommen davon Pakete in der Standarddistribution). Das erleichtern es Leuten Pakete zu installieren, die sich in ihrem Paketdepot befinden. Dies ist aber nicht notwendig: Nutzer können diese Abhängigkeiten auch manuell finden, indem Sie die Suchschnittstelle nutzen.

Der Build Service stellt verschiedene Wege bereit, diese Abhängigkeiten zu behandeln.

Als erstes können Sie die für die Abhängigkeiten nötigen Pakete direkt ihrem Projekt hinzufügen. Dies ist zweifellos der Ansatz, den Sie verfolgen müssen, wenn kein anderes Projekt das benötigte Paket baut. Normalerweise wurde das benötigte Paket schon von einem anderen Projekt gebaut. Wie können wir dessen Arbeit also nutzen?

Die zweite Option ist, das Paketdepot des anderen Projekts mit ihrem Depot zu verknüpfen. Dies erreichen Sie, indem Sie die Metadaten ihres Projekts bearbeiten. Sie müssen dort einfach nur das andere Paketdepot zu der Liste der Depots hinzufügen, in denen der Build Service beim Bau nach "Build-Requires"-Abhängigkeiten sucht. Dadurch wird ihr Paket erfolgreich gebaut und Sie haben das erste Problem gelöst, aber ihr Depot ist nicht "transitiv geschlossen": Nutzer müssen sich die nötigen Pakete selber besorgen. Nichtsdestotrotz ist dies eine gute Wahl, wenn es viele Abhängigkeiten zu einem anderen Projekt gibt und/oder Nutzer sowieso beide Paketdepots verwenden.

Die dritte Option nennt sich Verknüpfung/linking und erlaubt es ihrem Projekt, Pakete nutzen zu können, die bereits in einem anderen Projekt existieren. Wenn Sie ein Paket in ihr Projekt verknüpfen, werden Sie davon abhängige Pakete bauen können und das verknüpfte Paket wird sich auch in ihrem Projektpaketdepot befinden, wodurch Sie beide Probleme ohne doppelte Arbeit lösen.

Es gibt zwei Arten von Verknüpfungen: link und aggregate. Wenn Sie link nutzen, können Sie optional die Art und Weise ändern, auf die das Paket gebaut wird. Ihr Bau des Pakets wird eine andere Baunummer haben als das Paket des Originalprojekts. Beachten Sie, dass dies Nutzer verwirren kann, da Sie eine andere Version eines Pakets mit dem gleichen Namen bauen.

Wenn Sie das benötigte Paket nicht verändern müssen, sollten Sie aggregate an Stell von link nutzen. Wenn Sie aggregate nutzen, legen Sie eine "nur lesende" Verknüpfung an. Das Paket wird nicht innerhalb ihres Projekts gebaut; statt dessen wird das bereits gebaute Paket aus dem Originalprojekt in ihr Projekt kopiert. Für den Nutzer führt dies zu weniger Verwirrung, das es sich um die absolut gleichen Pakete handelt.

Der Build Service erkennt automatisch Änderungen in verknüpften Paketen und löst automatisch einen Neubau für jedes davon abhängende Paket aus.

Arbeitsablauf

Die folgenden Schritte zeichnen einen normalen Arbeitsablauf nach, um ein Projekt zu erstellen und ihm Pakete hinzuzufügen. In einem Beispiel aus der realen Welt könnte es natürlich sein. dass Sie an manchen Stellen nicht weiterkommen und diese wiederholen müssen, bis sie nicht mehr fehlschlagen. Dieser Grundriss soll ihnen vor allem ein Gefühl dafür geben, was wir zu erreichen versuchen.

Wir werden ihnen, soweit möglich, zwei verschiedene Wege zeugen:

• Den Web-Client-Weg
• Den Kommandozeilen-Weg (wir werden osc für unser Beispeil verwenden)

Schritt Eins - Anmeldung

Wenn Sie bereits über ein Build-Service-Konto verfügen ist dies der einfachste Schritt.

• Web-Client: Öffnen Sie http://build.opensuse.org/ und klicken Sie auf eine der Verknüpfungen "List of All Projects" oder "Watched Projects". Sie werden daraufhin angehalten, ihren Benutzernamen und ihre Passwort für den openSUSE Build Service einzugeben. Haben Sie dies passiert, sehen Sie eine Liste von Projekten und in der oberen, rechten Ecke können Sie eine Verknüpfung zu ihrem "Home Project" finden. Folgen Sie bitte dieser Verknüpfung.

• Kommandozeile: Als erstes müssen Sie den Kommandozeilenklient auf ihrem lokalen Rechner installieren. Sie können osc-Pakete für verschiedene Distributionen im openSUSE-Tools-Depot finden (Ja, dies ist ebenfalls ein Build-Service-Projekt). Nutzen Sie ihre bevorzugte Paketverwaltung um das osc-Paket zu installieren. Beachten Sie: Für SUSE Linux 9.3 oder älter benötigen Sie zusätzlich die Pakete python-elementtree und python-urlgrabber von hier.

Danach wechseln Sie in das Verzeichnis, welches Sie für ihre Projektdateien verwenden wollen. Nun wird sich jeder, der sich mit SVN auskennt, wie zu Hause fühlen: Versuchen Sie, ihr Home-Projekt aus-zu-checken

 osc checkout home:<Benutzername> 

(Ersetzen Sie <Benutzername> bitte durch ihren Anmeldenamen). Sie werden dann angehalten, ihr Passwort einzugeben - danach wird osc versuchen, Pakete in ihr Home Project aus-zu-checken und ein neues Verzeichnis namens home:<Benutzername> erstellen. Sie können ihre Einstellungen in der Datei ~/.oscrc anpassen.

Schritt Zwei - Erstellen und Hochladen von Paketen

Es ist nicht wirklich notwendig, in ihrem eigenen Home Project zu starten - da Sie auch Pakete direkt zu einem existierenden Projekt hochladen können - aber es ist ein guter Startpunkt und niemand sollte ein Home Project eines anderen Nutzers als Bauabhängigkeit verwenden. So können Sie ihr eigenes Home Project als "Sandkasten" benutzen, um Pakete zu testen welche dann, sobald alles in Ordnung ist, in andere Projekte transferiert werden können.

• Web-Client: Klicken Sie einfach auf die Verknüpfung [Add Package]. Sie sollten die drei folgenden Textfelder ausfüllen: "Name", "Title" und "Description". Verwenden Sie einfach den Paketnamen als "Name", die Paketzusammenfassung als "Title" und die Paketbeschreibung als "Description".

Danach klicken Sie auf die Verknüpfung [Add File] um ihrem Paket Dateien hinzuzufügen. Sie müssen mindestens den Quellkode ihres Pakets und eine .spec-Datei hoch laden.

KLÄRUNG Was benötige ich bei Debian-Pakete?

• Kommandozeile:

osc meta pkg -e home:<Benutzername> <Paketname>

osc wird eine XML-Vorlage in ihrem bevorzugtem Editor öffnen, in welcher Sie einfach die gleichen Dinge (Name, Title und Description) wie oben beschrieben eintragen. Rufen Sie nun

osc up

auf und Sie erhalten ein neues Verzeichnis mit dem Namen ihres neuen Pakets. Um Dateien über die Kommandozeile hinzuzufügen wechseln Sie einfach in das neue Verzeichnis und kopieren Sie die relevanten Dateien dorthin, Rufen Sie danach

osc add *

und die Dateien im Verzeichnis werden für die nächste Übertragung markiert. Die Übertragung können Sie mit folgendem Befehl starten:

osc commit

Schritt Drei - Paketdepot hinzufügen

Kehren Sie zu ihrer OBS home-Seite zurück. Sie sollten sich nun entscheiden, für welche Distributionsdepots Sie ihr Paket bauen wollen.

• Web-Client: Klicken Sie einfach auf [Add Repository] und wählen Sie eine der verfügbaren Distributionen und Plattformen aus.

• Kommandozeile: Lassen Sie sich als erstes eine Liste der verfügbaren Depots anzeigen

osc ls

Bearbeiten Sie dann ihre Paket-Metadaten;

osc meta prj -e home:<Benutzername>

und fügen Sie das Depot etwa so hinzu:

 <repository name="SUSE_Linux_Factory">
   <path project="SUSE:Factory" repository="standard" />
   <arch>x86_64</arch>
   <arch>i586</arch>
 </repository>

Hinweis: Der Eintrag repository="standard" dient lediglich zukünftigen Erweiterungen (Abzweige eines Depots).

Schritt Vier: Bauen Sie ihr Paket

Normalerweise wird ihr Paket für den Bauprozess eingeplant sobald es übergeben wurde oder sobald einige Dateien verändert wurden. Wenn ein benötigtes Paket neu gebaut wird, wird auch ihr Paket automatisch neu gebaut. Sie können auch manuell einen Neubau ihres Pakets auslösen, wenn Sie dies für notwendig erachten (machen Sie das aber bitte nicht zu oft, um Bauleistung für andere Pakete zu sparen).

Bauen Sie ihr Paket lokal

Manchmal kann es schneller gehen, ihr Paket auf ihrer lokalen Maschine zu bauen, anstatt auf die Ergebnisse des Build Service zu warten. osc unterstützt den lokalen Bau ihres Pakets falls ihre lokale Hardware es unterstützt (auf x86_64 können Sie für i586 und x86_64 bauen, auf i586 nur für i586).

 osc build <Plattform> <Architektur> <spec-Datei> [--clean|--noinit]

Wenn Sie den Bauvorgang als normaler Nutzer starten (gute Idee!) werden Sie nach dem root-Passwort ihrer lokalen Maschine gefragt. Sie können dies umgehen, indem Sie ihren Nutzer zu /etc/sudoers hinzufügen und ihre ~/.oscrc bearbeiten:

su-wrapper = sudo

osc wird sich mit den Depot-Servern verbinden und alle benötigten RPMs in /var/tmp/osbuild-packagecache/<Plattform>/<Depot>/<Architektur> als Pufferverzeichnis herunterladen. (Wenn Sie also schon ein komplettes Depot haben können Sie die RPMs in diesem Verzeichnis verknüpfen um riesigen Datenverkehr zu vermeiden.)

Für ein openSUSE_10.2-Depot können Sie beispielsweise die Box-DVD wie unten gezeigt verwenden:

 mkdir /mnt/openSUSE-10.2
 mount openSUSE-10.2.iso /mnt/openSUSE-10.2 -o loop
 mkdir -p /var/tmp/osbuild-packagecache/openSUSE\:10.2
 ln -s /mnt/openSUSE-10.2/suse /var/tmp/osbuild-packagecache/openSUSE:10.2/standard

Das oben gezeigte verschafft ihnen Depots sowohl für x86 als auch für x86_64.

Pakete können nun lokal wie folgt gebaut werden:

 osc build openSUSE_10.2 i586 beryl-core-snapshot.spec

osc wird eine chroot-Umgebung in /var/tmp/osc-build-root/ erstellen und mit dem Bau ihres Pakets beginnen. Wenn Sie nur kleine Änderungen vorgenommen haben, können Sie die Neuerstellung der Bauumgebung mit der Option --noinit verhindern. Wenn Sie annehmen, dass ihre chroot-Umgebung kaputt ist, können Sie einen kompletten Neubau mit der Option --clean veranlassen.

Nachdem ihre Pakete in dieser chroot-Umgebung gebaut wurden, können Sie die entstandenen Pakete in /var/tmp/osc-build-root/usr/src/packages/RPMS/ finden.

Die komplette Protokolldatei ihres lokalen Bauvorgangs wird in /var/tmp/osc-build-root/.build.log abgelegt.

Bauen Sie ihr Paket im Build Service

Das Bauen im Build Service ist einfacher als das lokale Bauen - kann aber länger dauern.

• Web-Client: Wenn Sie einen Neubau manuell auslösen wollen, klicken Sie einfach auf [Trigger Rebuild] am Fuß der Paketseite.

• Kommandozeile: Mit den optionalen Argumenten <Depot> und <Architektur> kann der Neubau auf ein bestimmtes Depot oder eine bestimmte Architektur beschränkt werden.

osc rebuildpac <Projekt> <Paket> [<Depot> [<Architektur>]]

Schritt Fünf: Überprüfen der Protokolldateien

Der Build Service erstellt für jeden Bau eines Pakets eine große Protokolldatei.

• Web-Client: Klicken Sie in der Paketansicht einfach auf die Verknüpfung [Build Log].

• Kommandozeile: Sie haben verschiedene Möglichkeiten - abhängig von ihren Bedürfnissen. (Wenn Sie sich im Paketverzeichnis befinden ist die Angabe Paketverzeichnis):

osc prjresults [Paketverzeichnis]

Zeigt die gesammelten Bauergebnisse eines ganzen Projekts an.

osc results [Paketverzeichnis]

Zeigt die Bauergebnisse eines einzelnen Pakets an.

osc buildlog <Plattform> <Architektur>

Zeigt die Protokolldatei eines Pakets an (Sie müssen sich innerhalb eines Paketverzeichnisses befinden).

Schemata erstellen

Schemata (engl. patterns) sind Dateien, die eine Liste von Paketen sowie eine Beschreibung enthalten, wofür diese Sammlung gut ist. (In der Zukunft wird der Build Service Schemata in Paketdepots exportieren, so dass diese in YaST sichtbar werden.) Zusätzlich erstellt der Build Service für jedes erstellte Depotschemata .ymp-Dateien. Diese .ymp-Dateien können von Nutzern für die Ein-Klick-Installation genutzt werden.

Kurz gesagt sind Schemata nützlich, um einen Satz von Software für einen speziellen Anwendungsfall zu installieren, ohne dafür extra Abhängigkeiten zwischen den Paketen erstellen zu müssen.

Das Erstellen von Schemata ist direkt über die API oder über osc möglich:

• Ein Schema im $EDITOR öffnen (erstellt es, falls es noch nicht existiert)

osc meta pattern -e <Projekt> <Schema>

• Existierende Schemata auflisten

osc meta pattern <Projekt>

• Ein existierendes Schema holen

osc meta pattern <Projekt> <Schema>

• Sie können auch eine bereits vorhandene Datei übertragen:

osc meta pattern --file <lakale_Datei> <Projekt> <Schema>

Zum Testen: Ein Klick im Konqueror oder einem anderen Browser auf eine .ymp-Datei sollte das Installationsprogramm starten, falls es von ihrem Browser doch nicht unterstützt wird, können Sie es als normaler Nutzer über die Kommandozeile versuchen:

/sbin/yast2 MetaPackageHandler http://download.opensuse.org/repositories/<Projekt>/<Distributionsversion>/<Schema>.ymp

Die folgende Datei ist eine Beispielschemadatei aus dem KDE:KDE4:STABLE-Projekt. Sie können sich die daraus erstellte .ymp-Datei hier anschauen.

<pattern
 xmlns="http://novell.com/package/metadata/suse/pattern"
 xmlns:rpm="http://linux.duke.edu/metadata/rpm"
>
    <name>KDE 4 Games</name>
    <summary>KDE 4 Games</summary>
    <description>A number of games for KDE 4.</description>
    <uservisible/>
    <category lang="en">Desktop Functions</category>
    <rpm:recommends>
      <rpm:entry name="kde4-kpat"/>
      <rpm:entry name="kde4-kmahjongg"/>
      <rpm:entry name="kde4-kmines"/>
      <rpm:entry name="kde4-kreversi"/>
      <rpm:entry name="kde4-ksudoku"/>
    </rpm:recommends>
    <rpm:suggests>
      <rpm:entry name="kde4-katomic"/>
      <rpm:entry name="kde4-kbattleship"/>
      <rpm:entry name="kde4-ksquares"/>
      <rpm:entry name="kde4-bovo"/>
      <rpm:entry name="kde4-kiriki"/>
      <rpm:entry name="kde4-kwin4"/>
      <rpm:entry name="kde4-kolf"/>
      <rpm:entry name="kde4-klines"/>
      <rpm:entry name="kde4-ksame"/>
      <rpm:entry name="kde4-lskat"/>
      <rpm:entry name="kde4-kgoldrunner"/>
      <rpm:entry name="kde4-kblackbox"/>
      <rpm:entry name="kde4-kbounce"/>
      <rpm:entry name="kde4-ktuberling"/>
      <rpm:entry name="kde4-knetwalk"/>
      <rpm:entry name="kde4-kjumpingcube"/>
      <rpm:entry name="kde4-kspaceduel"/>
      <rpm:entry name="kde4-konquest"/>
      <rpm:entry name="kde4-kshisen"/>
    </rpm:suggests>
</pattern>

Einige Tag-Beschreibungen:

<rpm:requires>
<rpm:entry name="example" />
</rpm:requires>

<rpm:recommends>
<rpm:entry name="example" />
</rpm:recommends>

<rpm:suggests>
<rpm:entry name="example" />
</rpm:suggests>

Siehe auch

• Allgemeine Tipps und Tricks zum Build Service

• Wie Sie ihre Änderungen zu Paketen von Anderen beitragen

• Detaillierte Beschreibung verschiedener Arbeitsabläufe

• Neuigkeiten rund um den Build Service

• Anleitung zur Erstellung von Paketen für mehrere Distributionen

• Plugins für osc schreiben

• Qualitätssicherung für RPMs/RPM-spec-Dateien prüfen