openSUSE:Build Service Anleitung
Inhaltsverzeichnis
- 1 Voraussetzungen
- 2 Anforderungen
- 3 Terminologie
- 4 Arbeitsablauf
- 5 Weitere Infos
Voraussetzungen
Sie sollten ein grundsätzliches Verständnis für RPMs haben und wie sie erstellt werden. Lesen Sie auch die Paketbau Richtlinien für openSUSE oder ein ähnliches Dokument von anderen unterstützten Paketsystemen, wie dpkg. Dieses Dokument ist kein Ersatz für das Paketbaudokument, was sie über dem obigen Link finden.
Sie sollten mit der Quellcode-Umgebung, das Ihr Projekt verwendet, vertraut sein. Der Build Service kann einige gewöhnliche Fehler umgehen und wird versuchen, Sie im Fall von Fehlern zu führen. Wir haben eine Build Service-Mailingliste, die eine Quelle für Hilfe und Anleitung sein kann. Wie auch immer, Entscheidungen darüber, welche Patches anzuwenden sind, welchen Compiler Sie verwenden usw., ist Ihre Sache.
Anforderungen
Um den Build Service verwenden zu können, müssen Sie sich mit Ihrem openSUSE Account anmelden (er ist die Gleiche wie im Wiki, bei Bugzilla ...). Wenn Sie noch kein Benutzerkonto haben, klicken Sie auf den Link zur "Anmeldung" oben auf dieser Seite, um eine Anmeldung zu erstellen. Beachten Sie bitte, wenn Sie Ihr Passwort eines Tages ändern, müssen Sie auch ~/.oscrc ändern. Wenn Sie das nicht machen und die ocs Kommandos eingeben, wird es den Server niemals einbeziehen. Das Benutzerkonto könnte nach wiederholten Versuchen mit einem falschen Passwort blockiert werden.
Terminologie
Der Build Service enthält Projekte (Sie können hier eine Liste von ihnen einsehen). Jedes Projekt enthält die Resourcen, die benötigt werden, um eines oder mehrere Pakete (z.B. RPMs/DEBs/etc.) zu bauen. Diese Mittel schließen Quellarchive, Patch-Dateien, Spezifikationsdateien usw. ein. Das Ergebnis eines Projektes sind ein oder mehrere Repositorys. Ein Repository ist ein alt bekanntes Konzept: einfach ein Bündel von RPMs, die in einer Verzeichnishierarchie mit einigen index/meta-data Dateien organisiert sind. Das macht es für Werkzeuge wie Zypper leicht, nach Abhängigkeiten zu suchen und sie zu lösen. Die Repositorys, die ein Projekt erzeugt, korrespondieren mit den verschiedenen Betriebssystemversionen wie openSUSE 11.4, 12.1 usw.
Unter den existierenden Projekten gibt es "offizielle" openSUSE Projekte, die die RPMs bauen, die in die openSUSE Distributionen eingehen. Das "Fabrik" (Faktory) Projekt ist das Einführungs-Projekt, das die nächste Version von openSUSE gestalten wird. Es gibt eine Menge Gebiets-spezifische Projekte, solche wie Apache und Netzwerk:Telefonie. Schließlich hat jeder Benutzer sein eigens "Spielplatz"-Projekt, bezeichnet als home:username.
RPMs tendieren dazu, eine Menge Abhängigkeiten zu anderen RPMs zu haben. Oft kommen diese RPMs von verschiedenen Projekten innerhalb des Build Service. Das hat zwei bedeutende Folgen.
Erstens, wenn Ihr Paket von einem anderen Paket während der Laufzeit abhängt ("Requires"), so wird es oft auch während der Bauzeit davon abhängen (z.B., "BuildRequires"). Der Build Service sucht und findet nicht automatisch Bauabhängigkeiten für Sie ( anders als was in die Standarddistribution enthalten ist, für die Sie bauen). So müssen Sie irgendwie dem Build Service erzählen, wo die geforderten Pakete zu erhalten sind.
Zweitens ist es von Vorteil für ein Repository vorübergehend geschlossen zu sein, z.B. jede Abhängigkeit von jedem Paket in dem Repository ist ebenso in das Repository (Pakete in der Standarddistribution ausgenommen). Das macht das Leben leichter für Leute, die die RPMs installiern, das Ihr Projekt unterstützt. Aber das ist nicht gefordert: Benutzer können immer diese Abhängigkeiten finden, hauptsächlich indem sie die Suchschnittstelle verwenden.
Der Build Service bietet einige unterschiedliche Wege, um die Handhabung dieser Abhängigkeiten zu erleichtern.
Erstens, Sie können die geforderten Pakete direkt zu Ihrem Repository hinzufügen. Das ist sicherlich die Herangehensweise, die Sie nehmen müssen, wenn kein anderes Projekt das geforderte Paket baut. Typischer Weise ist es so, dass diese Pakete von irgend einem anderen Projekt bereits gebaut wurden. Prüfen Sie die Wiederverwendung dieser Arbeit.
Die zweite Option besteht darin, das Repository des anderen Projekts mit Ihrem Repository zu verlinken. Das wird als Schichtung (layering) bezeichnet. Das wird durch die Bearbeitung der Metadaten Ihres Projekts gemacht. Fügen Sie das andere Projekt-Repository als zusätzlichen Pfad hinzu. Dies ist eine einfache Ergänzung zur Liste der Repositorys, in denen der Bild Service nach den Abhängigkeiten während der Bauzeit: "BuildRequires" suchen wird. Das wird es Ihrem Paketbau ermöglichen, erfolgreich zu sein. Das löst das erste Problem aber überhaupt nicht das Problem "vorübergehend geschlossen": Die Benutzer werden die benötigten Pakete selbst abholen gehen müssen. Das ist eine gute Wahl, wenn es verschiedene Abhängigkeiten von Ihrem Projekt in ein anderes Projekt gibt und/oder die Benutzer möglicherweise von beiden Repositorys Gebrauch machen wollen.
Die dritte Option wir als Verlinkung (linking) bezeichnet und ist ein Weg, es Ihrem Projekt zu erlauben, ein Paket, das in einem anderen Projekt bereits vorhanden ist, wieder zu verwenden. Wenn Sie ein Paket in Ihr Projekt verlinken, wird es möglich sein, die abhängigen Pakete zu bauen und das Paket wird ebenso in Ihrem Repository des Projekts erscheinen. Damit werden beide Probleme ohne doppelte Arbeit gelöst.
Es gibt zwei Arten der Verlinkung: link und aggregate. Wenn Sie link verwenden, können Sie optional die Art, wie das Paket gebaut wird, modifizieren. Sie können Patches hinzufügen und den Bau für zusätzliche Repositorys ermöglichen. Ihr Bau des RPM des Paketes wird eine andere Baunummer haben als das Original, aus dem es gebaut wurde. Beachten Sie, dass das Verwirrungen bei Benutzern verursachen könnte. In Wirklichkeit bauen Sie eine andere Version eines Paketes mit der gleichen Bezeichnung.
Wenn Sie das benötigte Paket nicht verändern müssen, sollten Sie aggregate anstatt von link verwenden. Wenn sie aggregate verwenden, dann erzeugen Sie einen "read-only" Link. Das Paket wird nicht innerhalb Ihres Projektes gebaut, stattdessen wir das bereits gebaute Paket nur in Ihr Projekt aus dem Originalprojekt kopiert. So wird das gleiche RPM (mit der gleichen Baunummer) in beiden Projekten erscheinen. Für den Benutzer gibt es weniger Verwirrungen, weil die RPMs identisch sind.
Der Build Service entdeckt Veränderungen in verlinkten Paketen automatisch und löst Neubauten von jedem Paket, das von ihnen abhängt, aus.
Arbeitsablauf
Die folgenden Schritte beschreiben einen normalen Arbeitsablauf, um ein Projekt zu erstellen und Pakete zu ihm hinzu zu fügen. Natürlich könnten Sie bei einem wirklichen Projekt bei einigen Schritten Fehler machen und Sie müssen dann diesen Schritt wiederholen. Diese Beschreibung dient dazu, Ihnen nur das Gefühl dafür zu geben, was Sie versuchen zu erreichen.
Wir werden Ihnen zwei unterschiedliche Wege zeigen:
- Der Web Client Weg;
- Der Kommandozeilen Weg
- Eine alternative Methode ist der MonoOSC Weg, eine Anleitung, die bereits hier vorhanden ist.
Schritt eins – Login und einmalige örtliche Projekteinrichtung
Wenn Sie bereits ein openSUSE Benutzerkonto haben, ist das der leichteste Schritt.
- Web Client:
Öffnen Sie Build openSUSE und verwenden Sie den Login-Link oben rechts, um sich einzuloggen. Danach steht Ihr Home-Projekt zur Verfügung, wenn Sie Ihren Benutzernamen anklicken.
- Kommandozeile:
Als erstes müssen Sie den Kommandozeilen-Client auf Ihrer Maschine installieren. Sie können die OSC-Pakete für verschiedene Distributionen im Repository für openSUSE-Werkzeuge herunterladen (ja das ist ebenso ein Projekt des Build Service. Verwenden Sie Ihren bevorzugten Paketmanager, um die OSC-Pakete zu installieren.
Hinterher wechseln Sie in das Verzeichnis, das Sie für Ihre Projektdateien verwenden wollen. Nun wird sich jeder, der sich mit SVN auskennt, wird sich "zu Hause" fühlen. Prüfen Sie Ihr Home-Projekt wie folgt:
cd <directory_to_contain_project_root> osc checkout home:<username> cd home:<username>
- (Bitte ersetzen Sie <username> durch Ihren Loginnamen). Sie werden nach Ihrem Benutzernamen und dem Passwort gefragt. Danach wird OSC versuchen, die Pakete in Ihrem Home-Projekt prüfen und ein neues Verzeichnis mit der Bezeichnung home:<Benutzernamen> erstellen. Sie können Ihre Einstellungen in der Datei ~/.oscrc bearbeiten.
Schritt zwei – Pakete erstellen & hochladen
Sie können Ihr Home-Projekt als eine "Spielwiese" verwenden, um Pakete zu testen, die zukünftig zu anderen, öffentlicheren Projekten transferiert werden, wenn alles in Ordnung ist.
- Web Client: Klicken Sie auf Ihren Benutzernamen, um Ihr Home-Projekt zu öffnen. Dann klicken Sie auf "ein neues Paket erstellen" im Tabellenblatt Pakete. Dann sollten Sie die folgenden drei Textfelder ausfüllen: "Bezeichnung" (obligatorisch), "Titel" und "Beschreibung". Verwenden Sie den Paketnamen als "Bezeichnung", die Paketzusammenfassung als "Titel" und die Paketbeschreibung als "Beschreibung".
Nachdem das Paket erstellt ist, gehen Sie zum Tabellenblatt "Quellen", um die Dateien für Ihr Paket hinzu zu fügen. Sie müssen den Quellcode Ihres Paketes hochladen und mindestens eine Spezifikationsdatei. Lesen Sie dazu auch die openSUSE:Paketbau Richtlinien.
- Kommandozeile:
osc wird eine XML-Datei als Vorlage in Ihrem bevorzugten Editor öffnen (basierend auf der Umgebungsvariablen EDITOR) und Sie können die gleiche Sachen hinzufügen, wie oben beschrieben (Bezeichnung, Titel und Beschreibung).
Nun rufen Sie
auf und Sie werden ein neues Verzeichnis erhalten, mit dem Namen Ihres neuen Pakets. Um Dateien über die Kommandozeile hinzu zu fügen, müssen Sie nur mit cd in das neue Verzeichnis wechseln und kopieren die relevanten Dateien (typischer Weise ein .tar.xz und Unterstützungsdateien).
Die openSUSE RPM-Pakete haben ihre Bauanweisungen in einer Spezifikationsdatei. Bitte lesen Sie die Paketbau Richtlinien, wie diese zu erstellen sind. Ein leichterer Weg besteht darin, eine Spezifikationsdatei eines ähnlichen Paketes zu kopieren und anzupassen oder aus einem Tar-Archiv, wenn möglich.
Wenn die Dateien fertig sind, rufen Sie
auf. Das wird die Dateien für die nächste Einreichung in ein Verzeichnis stecken. Um die Dateien einzureichen, führen Sie
aus. Ein "commit" löst den Buildprozess automatisch aus. Wie Sie den "commit" verschieben können, bis Sie die Pakete lokal erfolgreich gebaut haben, lesen Sie unten.
Schritt drei – Bauziele wählen
Nun müssen Sie auswählen, für welche Distribution (z.B. openSUSE 12.1, Ubuntu 12.04 usw.) Ihre Pakete gebaut werden sollten.
- Web Client: Gehen Sie zu dem Tabellenblatt "Repositorys" in Ihrem Projekt und klicken Sie auf Repositorys hinzufügen und wählen eine der verfügbaren Distributionen und Architekturen.
- Kommandozeile: Zuerst benötigen Sie eine Liste der verfügbaren Repositorys
dann bearbeiten Sie die Metadaten Ihres Projekts:
und fügen das Repository hinzu:
<repository name="openSUSE_Factory"> <path project="openSUSE:Factory" repository="standard" /> <arch>x86_64</arch> <arch>i586</arch> </repository>
project kann openSUSE:Factory, openSUSE:12.1, SUSE:SLE-11:SP2 oder so ähnlich sein. Der Ausdruck repository="standard" ist für zukünftige Erweiterungen (Forks eines Repositorys).
Schritt vier – Paket bauen
Ihr Paket ist automatisch für den Bau geplant, nachdem es gebunden ist oder sich einige Dateien geändert haben. Wenn ein gefordertes Paket umgebaut ist, wird Ihr Paket ebenso automatisch umgebaut.
Sie können ebenso, wenn es notwendig ist, einen Umbau auslösen:
Mit den optionalen Argumente <repo> und <arch> kann der Umbau auf ein spezielles Repository oder Architektur begrenzt sein.
Wenn Ihr Projekt mit home:Benutzername bezeichnet ist, können Sie nun Ihr Projekt auf http://download.opensuse.org/repositories/home:/Benutzername/ finden.
Pakete lokal bauen
Manchmal kann es schneller sein, Ihr Paket lokal auf Ihrer Maschine zu bauen anstatt auf die Ergebnisse aus dem Build Service zu warten. OSC unterstützt lokales Bauen Ihrer Pakete, wenn Ihre lokale Hardware das unterstützt (auf x86_64 können Sie für i586 und x86_64 bauen, auf i586 nur für i586).
Die neuesten Quellen verwenden
Verwenden Sie osc checkout (osc co) oder osc up, um sicher zu stellen, dass Sie die neuesten Quellversionen haben.
Wenn es ein Projekt ist, müssen Sie sich nicht abmelden:
osc co <project> <package>
oder
osc co <package>
oder
osc up
Den lokalen Bau durchführen
zum Beispiel
Wenn Sie den Bau als normaler Benutzer (gute Idee!) starten, werden Sie nach dem Root-Passwort Ihrer lokalen Maschine gefragt. Sie können das vermeiden, wenn Sie Ihren Benutzer zu /etc/sudoers hinzufügen und Ihre ~/.oscrc bearbeiten:
su-wrapper = sudo
und mit `visudo`, fügen Sie folgende Zeile als Root:
<Ihr Login Name> ALL = NOPASSWD: /usr/bin/build
zu der Konfiguration von sudo hinzu (natürlich ohne '<' und '>').
OSC wird sich mit dem OBS Repository-Server verbinden und alle benötigten RPMs nach /var/tmp/osbuild-packagecache/plattform/repository/arch als Cache-Verzeichnis herunterladen. Wenn Sie den Netzwerkverkehr vermeiden wollen, ist es möglich, den Cache vorher mit RPMs von einer DVD oder ISO zu befüllen. Dafür müssen Sie die RPMs von der DVD in das Cache-Verzeichnis kopieren.
Zum Beispiel können Sie für ein openSUSE 12.1 Repository eine DVD-ISO wie unten benutzen:
mount openSUSE-12.1.iso /mnt/ -o loop mkdir -p /var/tmp/osbuild-packagecache/openSUSE\:12.1/standard cp -r /mnt/suse/* /var/tmp/osbuild-packagecache/openSUSE:12.1/standard
Nun legen Sie die Erlaubnisse fest, da die DVD nicht schreibbar ist, aber OSC muss die Daten in den Cache schreiben:
find /var/tmp/osbuild-packagecache/openSUSE:12.1 -type d -exec chmod 755 {} \;
find /var/tmp/osbuild-packagecache/openSUSE:12.1 -type f -exec chmod 644 {} \;
Die Pakete können nun lokal gebaut werden:
osc build openSUSE_12.1 i586 <some-package-name>.spec
OSC erzeugt eine Chroot-Umgebung und startet den Bau Ihres Paketes. Wenn Sie nur gerinfügige Änderungen haben, können Sie den Umbau der Bau-Umgebung mit der Option --noinit vermeiden. Wenn Sie einen Verdacht haben, dass Ihre Umgebung zusammengebrochen ist, können Sie einen kompletten Neubau mit der Option --clean auslösen. Sie können das Chroot-Verzeichnis konfigurieren. Schauen Sie sich die Kommentare in Ihrer Datei ~/.oscrc an.
- OSC wird es ablehnen, Pakete von Projekten zu installieren, dem Ihr System nicht traut. Das kann passieren, wenn Ihr Paket mit einem Entwicklungsprojekt verlinkt ist und Ihr System ist nicht so konfiguriert, dieses Repository zu verwenden. Sie können den notwendigen GPG-Schlüssel erhalten, in dem ausführen:
sudo rpm --import - <<_END_KEY $(osc signkey offending-project) _END_KEY
Nachdem Ihre Pakete in dieser Chroot-Umgebung gebaut sind, können Sie Ergebnispakete unter /var/tmp/build-root/home/abuild/rpmbuild/RPMS/ finden (ältere Versionen von rpmbuild verwenden /usr/src/packages/RPMS/.
Wenn Ihr Paket einen URL-Download-Service verwenden, könnte es sein, dass Sie zuerst das folgende Kommando ausführen müssen:
Die komplette Logdatei ihres lokalen Baus ist unter /var/tmp/build-root/.build.log gespeichert.
Fehler beim lokalen Bauprozess korrigieren
Die Hauptursache warum Sie ein neues Paket für openSUSE oder eine andere Distribution kompilieren müssten, ist, um die Kompatibilität umzusetzen , wenn Ihr Paket für die Version und das Release Ihres Betriebssystems noch nicht kompiliert wurde. Auf diesem Weg könnten Ihnen neue Fehler während des Bauprozesses begegnen, die behoben werden müssen. Der einfachste Weg Fehler zu beheben, besteht darin, mit Root zur Bauumgebung zu wechseln und dort den Fehler zu beheben. Es kann sein, dass Sie openroot verwenden möchten, um zu X11 Zugang zu erhalten und alle anderen notwendigen Verzeichnisse eingehängt zu bekommen..
oder altmodisch und schwerfällig
chroot /var/tmp/build-root/ cd /home/abuild/rpmbuild/BUILD/your-package-dir ls or: openroot /var/tmp/build-root/ 'cd /home/abuild/rpmbuild/ILD/your-package-dir; ls; bash' ... exit
Abhängigkeiten
Wenn Sie während Ihres Baus einen Abhängigkeitsfehler erhalten, fügen Sie eine Zeile hinzu, die die Bauabhängigkeiten enthält, wie
In diesem Fall werden cmake und libkde4-devel installiert, bevor Ihr Paket gebaut wird.
Installation von extra Paketen für den Bau von Root
Für die Absicht der Fehlerbehebung könnte es nicht notwendig sein, extra Pakete zu Ihrem lokalen Root-Bau zu installieren, um Bau-bezogene Probleme zu beheben und Fehler zu beseitigen. Das kann mit Hilfe der Datei ~/.oscrc und der Variablen extra-pkgs durchgeführt werden. Zum Beispiel:
extra-pkgs = vim gdb strace valgrind
Installation von Privilegien
Wenn Sie eine Fehlermeldung wie diese erhalten:
error: Bad exit status from /var/tmp/rpm-tmp.qrRAn2 (%install)
bedeutet das, dass Ihr Schritt %install Fehl geschlagen ist ( und alle anderen zuvor gingen gut). Das kann sein, dass Schreibrechte vermisst werden, wenn Sie versuchen zum falschen Ort zu installieren. In diesem Fall fügen Sie das folgende Installationskommando zu Ihrer Spezifikationsdatei hinzu:
make install DESTDIR=%buildroot
Die Arbeit zurück an OBS reichen
Wenn Sie Ihr Verzeichnis <package> so haben, wie Sie es wollen, verwenden das untere Kommando, um Ihre Arbeit an OBS zurück zu geben.
Eine neue Datei zum Paket hinzufügen:
osc add
Eine Datei aus dem Paket löschen:
osc rm
Den Change-Log aktualisieren (ie. *.changes)
osc vc
Ihre aktualisierten Dateien an OBS zurück geben:
osc commit
Patches
Wenn Sie planen, eine Datei zu flicken, kopieren Sie es bevor Sie es bearbeiten zu .orig. Wiederholen Sie den beabsichtigten Schritt im Bauprozess bis er geklappt hat und erzeugen Sie dafür einen Patch. Um den Bau ausführlicher zu machen, könnte es sein, dass Sie ein "set -x" in Ihre Spezifikationsdatei einfügen wollen, um der Bash zu ermöglichen, alle ausführbaren Kommandos auf zu sagen (set +x schaltet das Aufsagen hinterher ab).
diff -Pdpru /var/tmp/build-root/home/abuild/rpmbuild/BUILD/your-package-dir/Makefile.orig \
/var/tmp/build-root/home/abuild/rpmbuild/BUILD/your-package-dir/Makefile \
>/osc/home:user/your-package-dir/my.patch
Nun fügen Sie den Patch der .spec-Datei hinzu, indem Sie im Header "Patch67:my.patch" auflisten und lassen es dann an der geeigneten Position (gewöhnlich %setup) im Bauprozess durch "%patch67 -p7" anwenden (-p7 zieht sieben Verzeichnisebenen ab, wenn Sie nicht die Datei-Verzeichnisse im Header der Patch-Datei manuell bearbeitet haben). Sie könnten es leichter finden, ein spezielles Programm zur automatischen Patcherzeugung zu verwenden, wie Quilt.
Schritt fünf: Prüfung der Log-Dateien
Der Bauservice produziert eine große Log-Datei für jeden Bau eines Paketes.
- Web Client: Klicken Sie auf den Link [Build Log] in der Paketansicht.
- Kommandozeile: Sie haben einige Auswahlmöglichkeiten, in Abhängigkeit von Ihren Bedürfnissen. (
packagedirist optional, wenn Sie im Paketverzeichnis sind):
osc prjresults [packagedir]
Zeigt die gesammten Bauergebnisse eines ganzen Projekts. Oder Sie geben ein:
osc results [packagedir]
Das Zeigt das Bauergebnis eines einzelnen Paketes.
osc buildlog <platform> <arch>
Zeigt die Log-Datei eines Paketes (Sie müssen innerhalb eines Paketverzeichnisses sein).
Pattern erstellen
Pattern sind Dateien, die eine Liste von Paketen gemeinsam mit einer Beschreibung enthalten, wofür sie geeignet sind. Zusätzlich erzeugt der Build Service .ymp-Dateien für jedes erzeugte Repository-Pattern. Diese .ymp-Dateien können vom Anwender für eine Einklick-Installation verwendet werden.
Kurz gesagt, Pattern sind zur Installation eines Software-Satzes für einen typischen Bedarf geeignet, ohne Abhängigkeiten zwischen Paketen zu erzeugen. Das Einreichen von Pattern ist möglich, indem Sie das API-Verzeichnis oder OSC verwenden:
- Um in $EDITOR ein Pattern zu öffnen (es erstellen, wenn es noch nicht vorhanden ist)
osc meta pattern -e <project> <pattern>
- Um vorhandene Pattern aufzulisten
osc meta pattern <project>
- Um ein vorhandenes Pattern zu erhalten
osc meta pattern <project> <pattern>
- Sie können ebenso eine vorhandene Datei einreichen:
osc meta pattern --file <local_file> <project> <pattern>
Zum Test: Das Klicken auf .ymp in Konqueror sollte den Installer starten. Sie können das Starten als normaler Benutzer von der Shell versuchen:
/sbin/yast2 MetaPackageHandler http://download.opensuse.org/repositories/<project>/<SUSE_Factory or openSUSE_10.2>/<pattern>.ymp
Die folgende Datei ist ein Beispiel-Pattern vom KDE:KDE4 Projekt. Sie können die erzeugte .ymp-Datei daraus hier sehen.
<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 Markierungs-Beschreibungen:
| Markierung | Beschreibung |
|---|---|
<rpm:requires> <rpm:entry name="example" /> </rpm:requires> |
Requires RPM Beispiel: dieses Paket muss installiert sein - andernfalls ist das Pattern nicht erfüllt. |
<rpm:recommends> <rpm:entry name="example" /> </rpm:recommends> |
Recommends RPM Beispiel: wenn verfügbar und alle Abhängigkeiten dieses Paketes sind erfüllt, würde das Paket installiert sein. Wenn das Paket nicht verfügbar ist, gibt es keine Fehlermeldungen. Wenn die Paket-Abhängigkeiten nicht getroffen werden, wäre das Paket sichtbar aber nicht installiert. |
<rpm:suggests> <rpm:entry name="example" /> </rpm:suggests> |
Suggests RPM Beispiel: würde im Pattern gezeigt werden aber nicht standardmäßig installiert |