Home Wiki > openSUSE:Zusammenarbeit im Build Service
Sign up | Login

openSUSE:Zusammenarbeit im Build Service

tagline: Aus openSUSE

Einführung

Der Open Build Service bietet verschiedene Wege der Zusammenarbeit. Der leichteste Weg ist, mehr Leuten Schreibzugang in einem Paket oder Projekt zu gewähren. Dieser Weg erlaubt es, einem kleinen Team eng und schnell zusammen zu arbeiten.

Wie auch immer funktioniert diese Vorgehensweise in vielen Fällen nicht:

  • Unbekannte Mitwirkende haben keinen Schreibzugriff und können darum keine Änderungen beitragen.
  • Das Vertrauen in ein Projekt sinkt mit der Zahl der Leute mit Schreibzugriff.
  • Auch Leute mit Schreibrechten möchten eine Durchsicht ihrer Änderungen vornehmen, bevor sie in einem Projekt aktiv werden.
  • Bedingte Änderungen in einem großen Projekt führen zu Situationen, wo das Projekt niemals mit dem Bauen aufhört. Änderungen zu Basispaketen können andere Pakete auf unbestimmte Zeit blockieren.

Darum bietet der Open Build Service einen anderen Weg, um Beiträge zu leisten. Sie können Änderungen in einem verzweigten Projekt vorbereiten und dann darum bitten, dass die Änderungen mit dem Original zusammen gefügt werden.

Große Projekte, wie KDE, GNOME, Apache und YaST benötigen oft eine andere Ebene der Überprüfung, bei denen Einreichungen, bevor sie im Hauptprojekt überprüft werden, platziert werden. Das ist zum Beispiel der Fall bei openSUSE:Factory. Dieses Projekt definiert ein Entwicklungsprojekt für jedes Paket. Der Open Build Service hilft den Benutzern, für diese Projekte zu entwickeln und die Beiträge dort einzureichen. Der Projekteigentümer des Entwicklungsprojekts kann dann alle Beiträge bei openSUSE:Factory einreichen. Dieser Prozess wird in folgender Präsentation dargestellt.

Ein Beispiel mit CLI

Unser CLI (Command Line Client) wird "OSC" genannt. Sie können hier in der Paketliste eine aktuelle Version für openSUSE 12.1 finden. Auf der Seite Werkzeuge finden Sie weitere nützliche Informationen.

Warnung! Diese Seite beschreibt die osc UI seit Version 0.119. Ältere Versionen hatten etwas andere Kommandos.

Hier ist ein anderes Beispiel, das die Anwendung eines Web-Clients, der Schichtung, der Verlinkung, das Patchen und Zusammensetzen für ein Projekt (PackageKit) erwähnt.


Wie füge ich meine Änderungen zu Paketen anderer Entwickler bei?

Sagen wir mal, Sie wollen an dem Paket openSUSE:Factory/initviocons arbeiten und später Ihre Arbeit beim openSUSE:Factory Projekt einreichen.

Das Folgende zeigt Ihnen Schritt für Schritt, was zu tun ist.
Ergänzende Informationen finden Sie auch in der OBS-Anleitung im Abschnitt Arbeitsablauf.

Ein abgezweigtes Paket erzeugen

Zuerst erzeugen wir einen Zweig (branch) von dem Paket, an dem wir arbeiten wollen, in unserem Home-Projekt.

# osc branch <Quell-Projekt> <Quell-Paket>
osc branch openSUSE:Factory initviocons

Dieses Kommando erzeugt zuerst ein neues persönliches 'Zweig-Projekt' unter home:$Sie selbst:branches, wenn es bis jetzt noch nicht existierte. Dieses Zweigprojekt besitzt die gleiche Baueinstellung wie das originale Quell-Projekt. Dann erzeugt das Kommando ebenso das Paket innerhalb des Zweiges als als eine Quellverknüpfung (source link).

Viele Pakete haben ein 'Entwicklungsprojekt' definiert. In diesem allgemeinen Fall erzeugt der Server eine Verknüpfung zu diesem Entwicklungs-Projekt anstatt zum Quell-Projekt. Sie sehen das in der Ausgabe des 'OSC-Zweiges' wie folgt:

# Zweig eines Paketes von Factory, der aber in einen anderen Projekt entwickelt wird
osc branch openSUSE:Factory glib2

Es erzeugt home:$yourself:branches:GNOME:UNSTABLE/glib2.

Das stellt sicher, dass Ihre Änderungen dem vorhandenen Fluss an Änderungen im wirklichen Home des Paketes folgen.

Arbeit an Änderungen

Nachdem Sie nun ein abgezweigtes Paket haben, können Sie damit beginnen, daran zu arbeiten. Die folgenden Kommandos:

osc checkout home:$yourself:branches:openSUSE:Factory/initviocons
cd home:$yourself:branches:openSUSE:Factory/initviocons

checken das Paket an Ihr lokales Dateisystem aus. Der Quell-Link ist erweitert. Wenn Sie ein Paket abzweigen, wird ein Link zum Original erzeugt, anstatt alles zu kopieren. Mit diesem Link bleibt unser Zweig aktuell, wenn sich das Original verändert. Um an Ihrem Zweig zu arbeiten, wollen Sie die wirklichen Paketquellen haben und nicht eine Datei _link XML. Per Standard erweitert das Auschecken eines verlinkten Paketes den Link zum Inhalt des Originalpaketes. Sie erhalten darum die originalen Quellen/Dateien plus die vorhandenen Änderungen in das Checkout.

# nun arbeite mit ihm
vi ...
osc status
vi ...
osc vc

Ihre Änderungen können neue Funktionen, Fehlerbeseitigungen, Verbesserungen usw. sein.

# Sie bauen lokal
osc build

Das lokale Bauen hilft, während Sie entwickeln, die Verweildauer zu reduzieren. Es gibt für den Open Build Service keine Notwendigkeit, wenn Sie eine Änderung machen, jedes Mal darauf zu warten, bis das Bauen Ihres Paketes beendet ist (oder der Bau fehl schlägt).

Sobald Sie fertig sind, ist es Zeit, den Open Build Service über Ihre Änderungen zu informieren:

# Übergabe der Änderungen
osc commit -m "dies und das geändert"

Ihre Änderungen gehen zum Server und der Bau wird eingeplant.

Obwohl Sie die erweiterten Quellen ausgecheckt haben, gibt es keine Notwendigkeit Patches gegen das Basispaket selbst zu erzeugen. Der Open Build Service sorgt für all das, indem es Ihren Zweig und das Original vergleicht und Unterschiede auf dem Open Build Service erzeugt.

Nach einer gewissen Zeit können Sie prüfen, ob alles funktioniert mit:

# Prüfung, ob gebaut
osc results

Manchmal werden Sie sehen wollen, wie Ihre Arbeit sich vom Originalpaket unterscheidet. Sie wollen zum Beispiel mit jemandem über Ihre Änderungen diskutieren. Oder Sie wollen einfach nur sehen, was andere Entwickler in der gleichen Zeit gemacht haben. Dafür verwenden Sie:

# zeigt Unterschiede zwischen Ihrer Version in der Version in openSUSE:Factory
osc rdiff home:Sieselbst:Zweige:openSUSE:Factory initviocons

Fehler beheben

osc build hinterlässt einige Dateien im Bauverzeichnis, die Ihnen helfen können, das Problem zu finden. Die neueste Erklärungsausgabe von osc build ist:

Das Buildroot war: /var/tmp/build-root

Wenn Sie dort hin gehen, können Sie die folgenden interessierenden Dateien untersuchen:

Bezeichnung Bedeutung
.build.log Untersuche den Bau und identifiziere den Fehler
.build.command Das verwendete Kommando, um den aktuellen Bau auszuführen
.build.packages Das Verzeichnis, wo sich die Objekt-Dateien befinden

Wenn der Bau fehl schlägt, könnten Sie versucht sein, etwas im Bau-Verzeichnis zu ändern. Das ist gewöhnlich keine gute Idee, weil das Kommando osc build gewöhnlich dort alles verwirft ( rm -rf ) und von neuem beginnt. Diese Strategie ist unglücklicher Weise nicht für schrittweise Änderungen durchführbar, wenn der Bau eine lange Zeit benötigt, was für große Projekte leicht möglich ist. Um das Problem zu umgehen, sehen Sie sich die Datei .build.command an. Sie enthält gewöhnlich eine Zeile in der Form

rpmbuild -ba package.spec

Das Kommando wird, alles was Sie gebaut haben, verwerfen. So ist es auch nicht von Nutzen. Wie auch immer, dieses Kommando wird möglicher Weise den Bau fortsetzen:

rpmbuild -bc --short-circuit package.spec #kompiliert
rpmbuild -bi --short-circuit package.spec #installiert

Diese Optionen werden im Detail unter Fedora RPM Guide erklärt.

Ihre Änderungen einreichen

Warnung!Diese Funktion ist momentan nicht in eingefrorene Projekte wie openSUSE:11.0, Fedora:9 oder die Aktualisierungs-Projekte implementiert. Das erfordert Änderungen in unserer Wartungsarbeit, was später kommen wird. :)

Wenn Sie zufrieden sind und glauben, dass Ihre Änderungen eine gute Chance haben, vom Wartungsteam der Upstream-Projekte akzeptiert zu werden, können Sie voran gehen und um einen Vorschlag bitten.

osc submitrequest -m 'version update to 3.3'

Dies reicht die Änderungen des Paketes in Ihrer lokalen Arbeitskopie zum Projekt, das im Quelllink definiert ist ein.

Sie können das ebenso ohne einer ausgecheckten Arbeitskopie durchführen, indem Sie folgendes aufrufen

osc submitrequest home:$yourself:branches:openSUSE:Factory initviocons openSUSE:Factory -m 'version update to 3.3'

Dies erzeugt ein Ersuchen, das anzeigt, dass Sie etwas großartiges für die Factory anbieten ;-) Das Wartungsteam des Projektes werden das schnell überprüfen. Wenn die Änderung akzeptabel ist, können sie es in ihr Projekt einpflegen. Wenn mehr Arbeit erforderlich ist, können sie Ihnen weitere Rückinformationen geben.

Wie geht es mit meinem Beitrag weiter?

Der Wartungsmitarbeiter eines Projektes (wie openSUSE:Factory) ist angehalten, den Beitrag zu prüfen (bsw. für eingereichte Anträge) wie diesen:

 % osc request list openSUSE:Factory
37   new         home:poeml/initviocons  ->  openSUSE:Factory/initviocons    'version update to 3.3'

Der Wartungsmitarbeiter wird sich die Änderung ansehen, in dem er sie mit der vorhandenen Paketquelle vergleicht. Entweder er akzeptiert diese oder gibt eine Erklärung mit Begründung ab.

 % osc request show -d 37
Request to submit (id 37): 

    home:poeml/initviocons  ->  openSUSE:Factory/initviocons

Source revision MD5:
    f839321325a0b5582def283c3520bf13

Message:
    'version update to 3.3'

State:   new          2008-03-20T19:57:02 poeml



changes files:
--------------
--- initviocons.changes
--- initviocons.changes
@@ -20 +20 @@
-    which sends a characteristic primary da
+    which sends a characteristic primary DA
[...]


Danach kann der Wartungsmitarbeiter den Beitrag akzeptieren:

osc request accept 37

Oder zurückweisen mit einer Begründung:

osc request decline -m "changelog wird vermisst, aber laut Richtlinie gefordert" 37

Beispiel mit Web-Schnittstelle

Dies beschreibt, wie man die Quellen über die Web-Schnittstelle ändert. Sie finden das für openSUSE unter http://build.opensuse.org.

Die Web-Schnittstelle ist nett, um eine Übersicht zu erhalten und einfache Dinge zu ändern, wie offensichtliche Fehler oder Paketbeschreibungen. Um komplexere Änderungen zu machen, wie die Behebung von Konflikten durch Zusammenführungen, wird das CLI empfohlen.

Wie trage ich meine Änderungen zu Paketen von jemand Anderem bei?

Sagen wir mal, Sie wollen an dem Paket openSUSE:Factory/initviocons arbeiten und später Ihre Arbeit an das openSUSE:Factory Projekt zurück geben.

Das Folgende zeigt Ihnen, was Schritt für Schritt zu tun ist.

Erzeugen eines Zweig-Paketes

Sie müssen einen Zweig erzeugen, der grundsätzlich eine Kopie des Originalpaketes ist, da Sie gewöhnlich keinen Schreibzugriff auf das Ziel haben. Oder Sie wollen zuerst experimentieren bevor Sie Ihren Code an alle Benutzer übergeben.

Der Zweig wird standardmäßig immer mit Änderungen vom Ursprungspaket versehen.

Für openSUSE:Factory gehen Sie zur Paketliste und finden Sie Ihr Paket.

Erzeugen eines Zweig-Projektes

Zuerst erzeugen wir ein Zweigprojekt von dem Paket an dem wir arbeiten wollen in unserem Home-Projekt. Klick auf das Menü "Actions" und danach auf "Branch package".

Der Server erzeugt ein neues Projekt unter home:$yourself:branches, das Zweig-Projekt. Dieses Zweig-Projekt besitzt die gleichen Baueinstellungen wie das originale Quell-Projekt. Das Kommando erzeugt ebenso das Paket innerhalb des Zweiges als ein Quell-Link.

Viele Pakete definieren ein 'Devel Project'. In diesem allgemeinen Fall erzeugt der Server einen Link zum Entwicklungs-Projekt anstatt zum Quell-Projekt. Sie sehen, das ist der 'osc Zweig', wie hier:

Arbeit an Änderungen

Klicken Sie auf die Registerkarte "source files" und bearbeiten Sie Ihre Quellen wie gewollt. Sie sollten warten und schauen, ob sie wirklich bauen.

Sie mögen ebenso die Pakete herunter laden wollen und ausprobieren, ob Ihre Änderungen wirklich einen Unterschied während der Laufzeit machen.

Ihrer Änderungen für die Zusammenfügung einreichen

Warnung!Diese Funktion ist momentan nicht in eingefrorene Projekte wie openSUSE:11.0, Fedora:9 oder die Aktualisierungs-Projekte implementiert. Das erfordert Änderungen in unserer Wartungsarbeit, was später kommen wird :)

Wenn Sie zufrieden sind und glauben, dass Ihre Änderungen eine gute Chance haben, vom Wartungsteam der Upstream-Projekte akzeptiert zu werden, können Sie voran gehen und um einen Vorschlag bitten.

Sie können entweder eine Einreichungsanfrage über das Menü "Actions" erzeugen oder den Link "Zeige den Unterschied und gib die Änderungen zurück" auf der Seite der "Quelldateien" finden.

Dies wird ein Ersuchen für den Zielautor erzeugen, der Ihre Änderungen durchsehen wird und sie gewöhnlich akzeptieren. Ihr abgezweigtes Paket wird gewöhnlich gelöscht, nachdem es zurück zusammengeführt wurde (ausgenommen, Sie lehnen das ab).

Spezielle Handhabung für openSUSE:Factory

Jedes Paket in openSUSE:Factory besitzt ein "Entwicklungs-Repository". Diese Entwicklungs-Repositorys werden für die Entwicklung des Paketes selbst verwendet. (Sie können das Entwicklungs-Projekt eines Pakete via osc meta pkg openSUSE:Factory <package> | grep devel "sehen".) Wenn Sie osc branch openSUSE:Factory <package> ausführen, sind Sie nicht überrascht, wenn Sie das Paket von einem anderen Ort erhalten, wenn Sie Änderungen für ein Paket in openSUSE:Factory machen möchten.

Um eine Einreichungsanfrage an openSUSE Factory zu richten (Beachten Sie: Das Akzeptieren einer Einreichungsanfrage im Entwicklungsprojekt löst nicht automatisch eine Einreichungsanfrage an Factory aus!), muss der Wartungsarbeiter des Entwicklungs-Projektes so etwas wie folgt machen:

       osc sr -m "- aktualisiertes Paket, aufgrund von foo bar" <devel:project> <package> openSUSE:Factory

So, wir haben hier zwei Abläufe:

Zweig, nicht-offizielles Entwicklungs-Projekt, Arbeitsablauf des Wartungsarbeiters

  1. osc branch openSUSE:Factory <package>
  2. osc submitrequest (sendet die Einreichungsanfrage an das Entwicklungs-Projekt)
  3. Der Wartungsarbeiter des Entwicklungs-Projektes akzeptiert via osc sr accept <id>
  4. Der Wartungsarbeiter des Entwicklungs-Projektes erzeugt eine neue Einreichungsanfrage an Factory
  5. Leute von Autobuild akzeptieren die Änderung

Arbeitsablauf des Wartungsarbeiters des Entwicklungs-Projektes

  1. Der Wartungsarbeiter des Entwicklungs-Projektes erzeugt eine neue Einreichungsanfrage an Factory
  2. Die autobuild (openSUSE:Factory team) Leute akzeptieren die Änderung
So für Wartungsarbeiter des Entwicklungs-Projektes ist es immer eine gute Idee, Ihre

Hermes-Benachrichtigungen zu konfigurieren, um über die Einreichungsanfragen an ihr Projekt informiert zu werden und/oder Einreichungsanfragen an ihr Projekt via

osc request list <devel:project>
zu prüfen.