Aus Fedorawiki.de

Dieser Artikel ist noch nicht vollständig. Du kannst helfen, ihn zu bearbeiten.

<b>Anmerkung:</b> Im folgenden soll an dieser Stelle in nächster Zeit eine Anleitung entstehen, die die notwendigen Schritte zur Integration eines RPM-Paketes in Fedora beschreiben soll. Es sollte dabei beachtet werden, dass dies keine 1:1-Übersetzung der englischen Packaging Guidelines ist. Für die aktuellsten und genauesten Informationen sollten diese zusätzlich herangezogen werden

Inhaltsverzeichnis 1 Allgemeine Hinweise zur Betreuung eines Paketes in Fedora 1.1 Welche Voraussetzungen man mitbringen sollte 1.1.1 Technische Vorraussetzungen 1.2 Die Aufgaben eines Maintainers 1.3 Abgabe des Paketes 2 Der Integrationsprozess im Detail 2.1 Auswahlkriterien für Pakete in Fedora Extras 2.2 Erstellung des RPMs 2.2.1 Einrichten der Buildumgebung auf dem lokalen PC 2.2.2 Namensgebung des Paketes 2.2.3 Erstellung der SPEC-Datei 2.2.3.1 Grundsätzliche Informationen in der SPEC-Datei 2.2.3.2 Suchen der Paketabhängigkeiten 2.2.3.3 Einträge in %files 2.2.3.4 Angabe des Changelogs 2.2.4 Bauen des Paketes 2.2.5 Test des Paketes mit rpmlint 2.2.6 Abschließender Test mit mock 2.2.6.1 Installation von mock 2.2.6.2 Pakete bauen in mock 2.3 Das Sponsorship-Modell 2.4 Der Review Request 2.4.1 Anlegen eines Bugzilla-Accounts 2.4.2 Erstellen eines Review-Prozess 2.5 Erstellen eines 'FAS'-Accounts 2.6 Integration in das Buildsystem von Fedora 2.6.1 notwendige Konfiguration des eigenen Systems 2.6.2 Import des Paketes

Allgemeine Hinweise zur Betreuung eines Paketes in Fedora

Welche Voraussetzungen man mitbringen sollte

Für die Erstellung und Betreuung von Paketen sollte man Kenntnisse im Umgang mit Linux besitzen. Außerdem sind Kenntnisse in der Entwicklung von Programmen und insbesondere über die Programmerstellung unter Linux hilfreich. Daneben sollte man in der Lage sein, Texte in englischer Spache zu lesen und zu schreiben.

Technische Vorraussetzungen

Neben einem funktionierenden Fedora System sind noch folgende technische Voraussetzungen zu beachten:

• Eine funktionierende Mail-Adresse.
• Ein PGP-Schlüssel, der für das Signieren der CLA benötigt wird.
• Ein SSH-Schlüssel (RSA) der für den Verbindungsaaufbau mit dem Versionsverwaltungssystem benötigt wird.

Die Aufgaben eines Maintainers

Der Maintainer betreut ein Paket in Fedora und ist u. a. der Mittelsmann zwischen den Endanwendern und den Entwicklern der paketierten Software. Er führt Anpassungen am Paket durch, um die vom vom Programmautor erstellte Software in Fedora integrieren zu können. Außerdem leitet er Fehlerberichte von Benutzern, die nicht fedora-spezifisch sind, an dem Programmautor weiter.

Fehlerbereinigungen, die von Maintainer erstellt wurden, sind, falls diese nicht fedora-spezifische Anpassungen sind, an dem Programmautor weiterzuleiten. Zweck dieser Regelung ist es, dem Autor der Software die Möglichkeit zu geben, die Fehlerbereinigungen in die Software einpflegen zu können, so dass eine separate Anpassung der Patches bei einer neuen Programmversion vermieden wird.

Abgabe des Paketes

Der Integrationsprozess im Detail

Auswahlkriterien für Pakete in Fedora Extras

Grundsätzlich besteht für (fast) jedes Paket die Möglichkeit der Integration in Fedora. Es gibt dabei allerdings ein paar Ausnahmen. Die wichtigste ist dabei, dass es sich natürlich um ein Open Source-Programm handeln muss. Als Lizenzen sind dabei nur diejenigen zulässig, die von der OSI akzeptiert sind (Liste der Lizenzen). Falls ein Paket mehrfach lizensiert wurde, sollte diejenige Lizenz gewählt werden, die dieses Kriterium erfüllt.

Im Besonderen kommt bei Fedora hinzu, dass Pakete, die zwar eine OSI-Lizenz haben mögen, aber dessen legaler Status unklar ist, nicht integriert werden dürfen. Dazu zählen z.B. Programme, die das Abspielen von MP3s oder kopiergeschützen DVDs ermöglichen. Eine aktuelle Liste findet sich bei fedoraproject.org.

Ein weiteres Ausschlusskriterium sind Pakete, welche Kernelmodule enthalten.

Pakete, die nicht in Fedora integriert werden könne, aber zumindesten frei verteilbar sind, künnen in rpmfusion.org integriert werden.

Wenn das Programm diese Kriterien erfüllt, ist eine Integration in Fedora möglich. Zurvor sollte allerdings überprüft werden, dass es nicht schon ein existierendes Paket gibt. Dies kann sichergestellt werden durch:

• eine Suche auf der schon im Buildsystem von Fedora Extras vorhanden Pakete
• eine Suche auf der Malingliste für Package-Reviews, ob schon ein Paket dort angekündigt wurde

Eine Suche über yum list Paketname ist dabei nicht ausreichend, da dies nur die schon integrierten Pakete auflistet, jedoch nicht diejenigen, die noch auf eine Integration warten.

Erstellung des RPMs

Einrichten der Buildumgebung auf dem lokalen PC

Da das Paket vorher auf dem eigenen PC erstellt werden muss, wird eine Buildumgebung benötigt. Der Erstellung dieser ist dabei schon ein eigener Artikel gewidmet: Buildumgebung

Namensgebung des Paketes

Die Namensgebung für normale Pakete sollte dabei dem Quellpaket entsprechen. Heisst dieser z.B. tolles_programm-0.4.5.tar.gz, lautet der Eintrag für %{name}

Name:           tolles-programm

Unterstriche (_), Pluszeichen (+) oder Punkte (.) sollten nicht benutzt werden.

Die SPEC-Datei sollte dabei dem Eintrag für %{name} entsprechen, in diesem Fall also tolles-programm.spec.

Es gibt dabei noch eine Reihe von Sonderfällen, die in den Naming Guidelines näher aufgeführt sind.

Erstellung der SPEC-Datei

Die einfachste Variante, eine neue SPEC-Datei zu erstellen, bietet ein Tool aus dem Paket rpmdevtools

rpmdev-newspec Paketname

("Paketname" muss dabei natürlich durch den richtigen Paketnamen ersetzt werden)

Dies erstellt im aktuellen Verzeichnis eine minimale SPEC-Datei mit dem Namen Paketname.spec. Dort enthalten sind schon die wichtigsten Einträge, die benötigt werden. Zudem werden einige Variablen, wie z.B. die Angabe des korrekten "BuildRoot schon eingetragen. Für bestimmte Pakettypen gibt https://fedoraproject.org/wiki/PackageMaintainers/CVSAdminProcedurees zudem angepasste Vorlagen, die mit der Option -t benutzt werden können. So erstellt z.B. ein fedora-newrpmspec -t python Pythonpaket.spec eine Vorlage für Pytonpakete. Alle möglichen Vorlagen sind dabei im Verzeichnis /usr/share/fedora/ zu finden.

Grundsätzliche Informationen in der SPEC-Datei

Zu den grundsätzlichen Informationen gehören zum einen:

• Name
• Version
• Release
• Summary

Der Name des Paketes ist dabei durch den Punkt Namensgebung des Paketes schon vorgegeben. Bei der Version ist zu beachten, dass es ein paar Besonderheiten bei nicht-numerischer Versionierung gibt. Dies betrifft z.B. Vorab- oder CVS-Versionen. Im Feld Summary ist dabei eine kurze Beschreibung des Paketes einzutragen. Zu beachten ist dabei, dass der Satz nicht zu lang wird (maximal xx Zeichen), in englischer Sprache verfasst ist, nicht den Paketnamen (Name) in sich führt (Redundanz) und keinen abschließenden Punkt hat (Fehler bei rpmlint)

Die weiteren Informationen sind:

• Group
• License
• URL
• Source0

Das Paket muss dabei in eine Gruppe eingeordnet werden. Dies ist für die Kategorisierung im Paketmanager vonnöten. Die möglichen Gruppen finden sich dabei in der Datei /usr/share/doc/rpm-<version>/GROUPS. Die Lizenz muss dabei eine akzeptierte OSI-Lizenz sein (siehe Punkt Auswahlkriterien für Pakete in Fedora), als URL ist die Projekthomepage anzugeben und als Source0 ist eine vollqualifizierte URL anzugeben, unter der das Archiv mit den original Quelltexten aus dem Internet geladen werden kann. In Ausnahmefällen reicht die Angabe des Name des Quelltextarchives, wenn innerhalb des Paketes genau beschrieben wird, wie das Quelltextarchiv auf Basis einer Quelle aus dem Internet erstellt wurde. Unter %description ist zudem eine detaillierte Beschreibung des Paketes einzutragen.

Suchen der Paketabhängigkeiten

Die Angabe aller Abhängigkeiten ist einer der schwersten Aufgaben, die man zu bewältigen hat. Es ist dabei unumgänglich, dass alle angegeben sind, da sonst die Erstellung das Paketes im Buildsystem von Fedora fehlschlagen würde (sowie die Erstellung mit mock (s.u.)). Falls man aber nicht gerade eine frisch aufgesetzte Fedorainstallation zur Hand hat, dürften sich schon manche Abhängigkeiten (die vielleicht auch nicht explizit in der README des Paketes angegeben sind) auf dem eigenen System befinden. Diese sollten dabei aus dem lokalen System entfernt werden:

 fedora-rmdevelrpms

Dieses entfernt dabei alle devel-Pakete, die von keinen normalen Paketen benötigt werden. Beim ersten Aufruf wird das aber höchstwahrscheinlich fehlschlagen:

 ...but removal would cause unresolved dependencies:
  mutt-1.4.2.1-6.3.fc5 requires gettext
  nfs-utils-1.0.8-3.fc5 requires pkgconfig
  redhat-lsb-3.0-9.2 requires /usr/bin/m4
  redhat-lsb-3.0-9.2 requires /usr/bin/gettext
  redhat-lsb-3.0-9.2 requires /usr/bin/msgfmt
  system-config-printer-0.6.151.8-1 requires m4
Skipped.

Hier hat man nun die Wahl:

• man entfernt die sonstigen devel-Pakete von Hand oder
• man entfernt die angegebene Pakete (mutt, nfs-utils, redhat-lsb, system-config-printer) und lässt das Script nochmal laufen

Wenn man dann rpmbuild aufruft, wird dieses in den Punkten, die einem ./configure und make entsprechen, mit Fehlern abbrechen, da die benötigten devel-Pakete ja nicht mehr vorhanden sind. Jetzt sollte dabei die angegebene Abhängigkeit (die nicht zwangsläufig mit einem Paketnamen aus Fedora Core identisch sein muss) über yum nachinstalliert und der Vorgang wiederholt werden. Dies macht man solange, bis keine Pakete mehr fehlen und rpmbuild beim folgenden Punkt hängenbleibt.

Schwieriger wird das allerdings, wenn die Abhängigkeiten keine klassischen Devel-Pakete sind, sondern z.B. python-Pakete, die aber dennoch gebraucht werden. Diese entfernt das Script nicht, so dass man sich in diesem Fall auf die README oder den abschließenden Test in mock verlassen muss.

Eine Reihe von essentiellen Paketen müssen (und sollen) dabei nicht in der SPEC-Datei angegeben werden. Die aktuelle Liste findet sich dabei in den Packaging Guidelines.

Einträge in %files

Wenn das Programm durch die installierten Abhängigkeiten soweit durchcompiliert, wird es dennoch mit dem Fehler abgebrochen, dass "mehrere installierte, aber nicht gepackte Dateien" gefunden wurden und diese dabei in einer Liste ausgegeben. Alle dort enthaltenen Dateien müssen in der Sektion %files genannt werden. Zur besseren späteren Pflege sollten diese aber möglichst zusammengefasst werden. Dies kann z.B. durch ein Sternchen (*) geschehen, wenn sichergestellt ist, dass dadurch nur Dateien zugehörig zu diesem Paket erfasst werden. Ein Beispiel dafür wäre, dass das Paket "xyz" ein eigenes Verzeichnis /usr/share/xyz/ erstellt und in dieses Verzeichnis mehrere Dateien installiert. Dies könnte dann kurz so zusammengefasst werden.

/usr/share/xyz/*

Zudem müssen in %files immer, wenn möglich, sogenannte RPMMacros anstelle der direkten Angabe des Verzeichnisses benutzt werden. In diesem Beispiel würde daraus folgendes werden:

%{_datadir}/xyz/*

Da in diesem Falle ein eigenes Unterverzeichnis erstellt wird, muss ebenso das Verzeichnis als ganzes eingetragen werden.

%dir %{_datadir}/xyz/

Falls dies nicht geschieht, wird es beim entfernen des Paketes nicht wieder gelöscht. Ausserdem ist es eine Voraussetzung im Review-Prozess.

Angabe des Changelogs

Bei jeder Änderung des Paketes muss dabei diese Änderung im Changelog dokumentiert werden. Dies macht es später leichter, die Änderungen nachzuvollziehen. Falls durch die Änderung z.B. ein Bug gefixt wurde, sollte die Bugnummer zudem eingetragen werden:

* Wed Jun 14 2003 Joe Packager <joe at gmail.com> - 0:1.0-0.fdr.2
- Added README file (#42).

Bauen des Paketes

Das eigentliche Erstellen ist dabei ganz simpel, da alles, was dem entgegensteht, schon in den oberen Punkten ausgeräumt sein sollte:

rpmbuild -bb Paketname.spec

Test des Paketes mit rpmlint

rpmlint ist ein Tool, das vorhandene RPMs und SRPMs auf generelle Fehler hin überprüft. Fedora Extras setzt dabei voraus, dass es sowohl bei den erstellten RPMs (auch den debuginfo und devel) sowie dem SRPMs keine Ausgabe erstellt und somit auch keine Fehler gefunden hat. Dies besagt zwar nicht zwangsläufig, dass einer Integration in Fedora Extras somit nichts mehr im Wege steht, es ist aber ein Schritt dahin. Lediglich in Einzelfällen können Fehler dabei auch ignoriert werden. Dies wird aber im Review Process besprochen werden.

Aufgerufen wird es dabei durch einfache Angabe des zu prüfenden Paketes:

$ rpmlint gnome-commander-1.2.0-1.fc5.i386.rpm
W: gnome-commander devel-file-in-non-devel-package /usr/lib/gnome-commander/libgviewer.a
W: gnome-commander devel-file-in-non-devel-package /usr/lib/gnome-commander/plugins/libfileroller.a
W: gnome-commander devel-file-in-non-devel-package /usr/lib/gnome-commander/libgcmd.a
W: gnome-commander devel-file-in-non-devel-package /usr/lib/gnome-commander/plugins/libcvs.a
W: gnome-commander devel-file-in-non-devel-package /usr/lib/gnome-commander/plugins/libtest.a

Für viele Fehler enthält rpmlint dabei auch eine kleine Hilfe, die diese erklärt, z.B.:

$ rpmlint -I devel-file-in-non-devel-package
devel-file-in-non-devel-package :
A development file (usually source code) is located in a non-devel
package. If you want to include source code in your package, be sure to
create a development package.

Hier sollte also ein extra Devel-Paket in der SPEC erstellt werden.

Abschließender Test mit mock

Mock nimmt ein SRPM und baut es in einer chroot-Umgebung. Es werden (neben einigen Grundsätzlichen Paketen) nur die Pakete installiert, die in der entsprechenden SPEC-Datei als BuildRequires angegeben sind. So kann gut überprüft werden, ob alle zum Bau benötigten Pakete dort eingetragen sind. Das Schöne ist dabei, dass man so auch Tests für alle Fedoraversionen durchführen kann, indem man die gewünsche Version direkt mit angibt (z.B. FC5).

Installation von mock

Zuerst einmal sollte mock aber lokal installiert werden. Da es selbst Teil von Fedora Extras ist, geschieht dies einfach über yum:

Anschließend muss aber noch der Benutzer, der die Pakete mit mock testen soll, zu der Gruppe mock hinzugefügt werden.

(<Benutzer> muss dabei durch den Namen des Benutzersaccounts ersetzt werden.)

<b>Anmerkung:</b> Diese Änderung ist erst nach einem erneuten Einloggen in den jeweiligen Benutzeraccount wirksam.

Pakete bauen in mock

Will man Pakete für die installierte Version von Fedora in mock bauen, reicht folgender Aufruf:

mock <Pfad-zum-SRPM-Paket>

Will man Pakete für eine andere Version von Fedora bauen, muss dabei die Konfigurationsdatei für die entsprechende Version mit angegeben werden. Um z.B. Pakete für FC5 auf der Architektur i386 zu bauen, muss folgender Aufruf benutzt werden:

mock -r fedora-5-i386-core.cfg <Pfad-zum-SRPM-Paket>

Die Konfigurationsdateien befinden sich dabei im Verzeichnis /etc/mock/.

Es können dabei nur Pakete für die Architektur gebaut werden, die der benutzte Prozessor auch unterstützt. Für einen i386-Prozessor sind das z.B. i386-Pakete, für einen ppc-Prozessor ppc-Pakete. Ein x86_64-Prozessor kann dabei aber auch Pakete für i386 erstellen. Es muss dafür nur vorher die Architektur auf i386 gesetzt werden:

setarch i386 mock -r fedora-5-i386-core.cfg <Pfad-zum-SRPM-Paket>

Falls bei dem Erstellen des Paketes noch Fehler aufgetreten sind, melded mock diese in der dabei angegebenen Log-Datei. Diese sollte dann beseitigt, ein neues SRPM erstellt und der Vorgang von Neuem begonnen werden. Falls keine Fehler auftreten, kann mit dem Test für eine andere Fedoraversion fortgefahren werden.

<b>Tipp:</b> Es bietet sich an, das Paket auf den zur Zeit aktuellen Versionen von Fedora zu testen. Momentan sind dies neben devel FC11 und FC10

Das Sponsorship-Modell

Jeder Maintainer im Fedora Projekt benötigt, solange er nicht selbst Sponsor ist, einen sogenannten Sponsor.

Dieser Sponsor prüft, ob ein Neuling die Voraussetzungen erfüllt, um Maintainer im Fedora Projekt zu werden. Außerdem ist er für die Tätigkeiten des gesponsorten Maintainers verantwortlich.

Weiterhin soll der Sponsor insbeosndere Neueinsteiger bei möglichen Problemen unterstützen.

Der Review Request

Innerhalb des Review Prozesses wird das Paket von einen anderem Maintainer darauf geprüft, ob die für die Erstellung des Paketes geltenden Regeln eingehalten wurden. Erst wenn der Reviewer sein Ok gibt (d. h.: Das Paket wird APPROVED), kann das Paket in Fedora integriert werden.

Jeder Benutzer, der ein Bugzilla-Account besitzt, kann Anmerkungen zu einem Review erfassen. Aber nur Fedora Maintainer können ein Paket formell begutachten und der Aufnahme des Paketes zustimmen.

Anlegen eines Bugzilla-Accounts

Über New Account on bugzilla.redhat.com kann ein neues Bugzilla-Account erstellt werden. Die einzige Angabe, die hierfür benötigt wird, ist eine funktionieren E-Mailadresse.

Da es sich bei Bugzila um ein offenes Bugtracking System handelt, wird die Benutzung eine separaten Mailadresse empfohlen, um die Überschwemmung der normalen Mailadresse mit Spam zu vermeiden.

Der Bugzilla-Acoount wird nach Ausführung der in der Bestätigungsmail genannten Schritte aktiviert.

Erstellen eines Review-Prozess

Vor der Erstellung eines Review Requests sollte man den Inhalt der sPEC-Datei und das hieraus generierte Source-RPM auf einen Webspace hochladen.

Danach kann durch Aufruf von [1] ein Formular zum Erstellen eines Review Requests aufgerufen werden. Als Neueinsteiger sollte man beim Ausfüllen des Formulars darauf hinweisen, dass man einen Sponsor benötigt.

Dies kann dadurch geschehen, indem man nach dem Abschicken des formulars im bug als Blocker 'FE-NEEDSPONSOR' angibt.

Erstellen eines 'FAS'-Accounts

Als Neueinsteiger muss man unter [2] ein sogenantes FAS-Account anlegen. Nach dem Anlegen des Accounts kann man unter [3] die Mitgleidschaft für die Gruppe 'packeger' anfordern, die vom Sponsor besätigt werden muss.

Diese Gruppe erlaubt es alle Pakete im Versionsverwaltungssystem zu bearbeiten, deren Eigentümer oder Co-Maintainer man ist.

Integration in das Buildsystem von Fedora

Nachdem ein Reviewer der Aufnahme eines Paketes in das Fedora Projekt zugestimmt hat, ist ein sogenannter CVSAdmin Request zu erstellen.

notwendige Konfiguration des eigenen Systems

folgende zusätzliche Pakete sind zu installieren:

• bodhi-client
• fedora-cvs
• koji

Außerdem ist unter [4] ein SSL-Certifikat herunterzuladen, welches unter ¨/.fedora.cert auf dem eigenen Rechner abzulegen ist.

Import des Paketes

=== Bau des Paketes im Buildsystem ===