RPM-Bau für Anfänger

Seite: 12/27
(5396 Worte insgesamt im Text)
(17082 mal aufgerufen)  Druckerfreundliche Ansicht

Die einzelnen Sektionen des SPEC-Files

Wir wollen uns nun einmal die einzelnen Sektionen des SPEC-Files etwas genauer ansehen. Dabei ist der Kopf des SPEC-Files noch leicht zu erklären:

Präambel: Im Kopfteil des Pakets sollten leicht lesbare Informationen über das Paket, den Paketautor (und seine Email) sowie weitere Informationen stehen, welche für einen anderen Paketbauer evtl. wichtige Informationen liefern können. Bei vielen Distributoren erstellt diese Informationen ein Skript, weshalb hier meist nur generelle Informationen zu finden sind. Wichtig ist hier eigentlich nur, dass sämtliche Informationen durch das Voranstellen einer # als Kommentar gekennzeichnet werden.

Sollten Sie später innerhalb des SPEC-Files einen Kommentar einfügen, tragen Sie bitte auch in der darüber stehenden Zeile eine # ein, damit der Kommentar später leichter zu finden ist und die "Leerzeile" über dem Kommentar später nicht durch Skripte herausgelöscht wird.

[...]
%install
rm -rf $RPM_BUILD_ROOT
make DESTDIR=$RPM_BUILD_ROOT
install
#
# Emacs support
install -d $RPM_BUILD_ROOT/usr/share/emacs/site-lisp
install contrib/emacs/t-mouse.el* \
$RPM_BUILD_ROOT/usr/share/emacs/site-lisp
#
# start script and sysconfig template
install -m 755
[...]


norootforbuildDiese Funktion ist derzeit nur bei SUSE-RPMs implementiert, die automatisch über das build-Skript gebaut werden. Damit wird ein Paket als normaler Benutzer und nicht als root gebaut, was viele Sicherheitsvorteile bringt.
neededforbuildDiese Zeile hat derzeit nur eine Funktion innerhalb der Autobuild-Umgebung von SUSE und ist ausserhalb der Firma daher ohne Funktion. Sinn und Zweck ist (mal wieder) die Faulheit der Entwickler: wenn diese z.B. eine KDE-Anwendung distributieren, dann können Sie hier einfach kde3-packages angeben und die Autobuild-Umgebung fällt dann "BuildRequires" automatisch mit den richtigen Paketen, die für das erstellen eines KDE-Programms nötig sind.
BuildRequiresHier werden Pakete angegeben, die zum erstellen des neuen RPMs benötigt werden. Wenn Sie also eine C++ Anwendung als PRM zur Verfügung stellen wollen, werden Sie hier sicherlich als Paket den Kompiler gcc angeben müssen.
Oft mag es vorkommen, dass ein Paket bestimmte Bibliotheken benötigt. Dies erkennt man oft während des configure-Skripts, da hier bestimmte *.la-Dateien nicht gefunden werden. Eine Suche bei Google nach der entsprechenden Datei kann einen hier oft auf die richtige Fährte bringen und liefert dann das fehlende Paket. Ggf. befragen Sie einfach RPM selbst, zu welchem Paket eine Datei gehört: (rpm -qf /usr/lib/libgpm.a) und tragen dann dieses Paket unter BuildRequires ein.
usedforbuildDiese Zeile ist seit SUSE 9.1 obsolet und wurde durch BuildRequires abgelöst.
Name:Der Name des Paketes. Hier kann man den ASCII-Zeichensatz, Binde- und Unterstrich verwenden (a-z, A-Z, 0-9, -, _).
Licence:Die Lizenz, unter der das Paket verteilt wird. Notfalls nachfragen! Wenn nichts im Quelltext steht ist es NICHT GPL! Verwendet ein Paket mehrere Lizenzen, dann werden diese durch Kommata voneinander getrennt.
Group:Stelle, an welcher das Paket nachher z.B. mit YaST2 zu finden ist, wenn man die "Paketgruppenansicht" einschaltet. Eine Übersicht über die bei SUSE verfügbaren Gruppen findet man auf dem Novell- FTP- Server.
Autoreqprov:on = mit dieser Einstellung überprüft RPM selbstständig, welche zusätzlichen Pakete zum "Betrieb" des Paketes benötigt werden und trägt diese in der Zeile Requires ein.
Vorübergehend kann man diese Option hier mit "off" deaktivieren. Dies sollte jedoch nicht die Standardeinstellung sein.
Version:Versionsnummer des Quelltextes. Diese Versionsnummer sollte hier angegeben werden. Aber Achtung: RPM entscheidet anhand dieser Versionnummer welches Paket älter oder neuer ist. Dabei kann RPM leider nicht richtig mit Buchstaben umgehen. Deshalb sollte man - wenn irgendwie möglich - auf Buchstaben in Versionsnummern verzichten und statt dessen lieber eine weitere Ziffernspalte beginnen. Aus "1.0rc1" würde dann z.B. "1.0.1".
Release:Versionsnummer des späteren RPMs - diese Versionsnummer wird zusammen mit der Versionsnummer des Quellcodes bei einem Update des Pakets überprüft. Sind die Nummern des installierten RPMs höher als die des zum Update ausgewählten, wird ein Update abgelehnt. Sie sollten also jedesmal, wenn Sie ein RPM neu bauen, auch diese Releasenummer erhöhen. Bei einem Update des Quelltextes hingegen wird die Versionsnummer erhöht und die Releasenummer wieder auf 0 heruntergesetzt.
Es hat sich inzwischen eingebürgert bei Tests die Releasenummer "0" zu vergeben und erst wenn alles funktioniert die Releasenummer auf "1" zu setzen und das Paket zu veröffentlichen.
Bitte verwenden Sie auch für die Releasenummer keine Buchstaben oder andere Sonderzeichen. RPM kann damit oft nicht vernünftig umgehen und ein einmal installiertes RPM-Paket läßt sich nur noch Updaten, wenn sich die Versionsnummer ändert.
SUSE verwendet in letzter Zeit häufig zweistellige Release-Nummern der Pakete. Hier will man auf die marginalen Unterschiede zwischen verschiedenen Produktversionen aufmerksam machen (SLES <> SL).
Summary:Kurze, knackige Zusammenfassung, die dem Benutzer sagt, was das Paket enthält. Diese Zusammenfassung wird bei Abfragen über den Paketmanager angezeigt und auch die Tools der einzelnen Distributionen zeigen die hier enthaltene Kurzinformation an. Deshalb sollte man hier keine kompletten Sätze sondern wirklich nur ein kurzes Statement formulieren, das dem Anwender die Bedeutung dieses Pakets klar macht.
Description:Ausführliche Beschreibung des Pakets. Diese wird bei einem rpm -qpi *.rpm angezeigt und sollte das Paket so gut wie möglich beschreiben.
Standardsprache ist Englisch - sowohl für die "Summary" als auch für die "Description".
Wenn Sie ein Paket in mehrere Subpakete (diese werden mit dem Namen des Hauptpakets, einem "-" und dem Namen des Subpakets benannt) aufsplitten möchten, müssen Sie auch für jedes dieser Subpakete eine eigene "Summary" und eine eigene "Description" verfassen. Beispiel:
%package devel
Summary: Development package for ...
Summary(de): Entwicklungspakete für ...
%description devel
Development package for ...
%description devel -l de
Entwicklungspakete für ...

Weitere Sprachen sollten Sie nur ins SPEC-File aufnehmen, wenn dies unbedingt nötig ist. Denken sie daran, dass die hier gemachten Angaben in die RPM-eigene Datenbank aufgenommen werden und diese Datenbank mit zunehmender Größe immer langsamere Zugriffszeiten hat.
URL:Die URL soll angeben, wo man die Quelltexte des Pakets beziehen kann. Wenn möglich kann hier die genaue URL zum Quelltext angegeben werden. Falls sich diese nicht eindeutig feststellen läßt ist aber auch die Homepage des Projektes zulässig.
Autors:Die eigentlichen Autoren des Programms. Diese sollten aus dem Quelltexten ersichtlich sein oder auf der Projekt-Homepage stehen. Notfalls sollte man per Email nachfragen. Da die hier gemachten Angaben durchaus von RPM-Datenbanken indiziert und auch im Internet angezeigt werden, ist die Angabe von Email-Adressen inzwischen leider unüblich geworden, da die Autoren ansonsten oft mit SPAM überschwemmt werden.
Source:Name des eigentlichen Paketes - also meist des Tarballs. Mehrere Dateien werden einfach durchnummeriert und können später über das Macro %SOURCE0 bzw. %SOURCE1 aufgerufen werden. Gewöhnen Sie sich ruhig schon so früh wie möglich daran, Macros zu benutzen und tragen Sie hier einfach %{name}-%{version}.tar.bz2 ein, sofern der Quelltext diese Struktur aufweist. (Denken Sie daran: "zippen" Sie die Dateien so klein wie möglich!)
Packager:Hier wird der Name des Paketbauers eingetragen - in der Regel also Ihr Name. Denken Sie bei der Angabe Ihrer Email-Adresse an den Hinweis unter "Authors" bezgl. SPAM.
NoSource:Für Dateien, die zwar zum Erzeugen eines RPMs genutzt werden, die aber aus lizenzrechtlichen Gründen nicht mit in das Source-RPM kommen dürfen. Dies kann bei kommerziellen Paketen, die die Quelltexte nicht freigeben, durchaus der Fall sein. Haben Sie mehrere solcher Quelltexte, werden diese ähnlich wie unter "Source" beschrieben durchnummeriert.
Patch:Name einer Patchdatei. Auch hier sind mehrere Dateien möglich, die dann wieder durchnummeriert werden. (Patch1, Patch2, Patch3, ...)
PreReq:Weist RPM an, die hier gelisteten Pakete (sofern vorhanden) zuerst zu installieren. Wichtig bei RPM-Aufrufen über die Kommandozeile oder bei Erstinstallationen. Sind die hier aufgeführten Pakete nicht vorhanden, wird die Installation abgebrochen.
Provides:Bietet zusätzlich zum eigentlichen Paketnamen andere Namen oder Funktionen mit an. z.B. "mailreader" oder "browser".
Damit kann RPM anderen Paketen dieses Paket anbieten, wenn diese eine solche Funktion über "Requires" anfordern.
Requires:Weist RPM an, zu überprüfen, ob die hier gelisteten Pakete im laufenden System installiert sind. Ansonsten wird die Installation abgebrochen. Achtung: hier nur diejenigen Pakete einfügen, die von "AutoReqProv" nicht erkannt werden.
Obsoletes:Wenn das Paket ältere Pakete ersetzt oder umbenannt worden ist, dann kann hier der alte Name angegeben werden, damit RPM wieder Abhängigkeiten auflösen kann.
BuildRoot:Hier sollte der Pfad zu einer "Build- Root- Umgebung angegeben werden (meist %{_tmppath}/%{name}-%{version}-build).
In diese Umgebung hinein werden später die fertig kompilierten Binaries und alle das neue Paket betreffenden Dateien gepackt. Dabei wird hier dann das normale Dateisystem nachgebildet, d.h. wenn Sie z.B. eine Datei später unter /usr/sbin ablegen möchten, legen Sie im %install-Abschnitt später das Verzeichnis innerhalb der BuildRoot-Umgebung mit install -d -m 700 %buildroot/usr/sbin an und installieren bzw. kopieren dort hinein dann die entsprechenden Dateien.
Damit können Sie später dann auch ganz einfach kontrollieren, ob Sie in Ihrem fertigen Paket etwas vergessen haben: vergleichen Sie einfach die Dateien im $RPM_BUILD_DIR-Verzeichnis (/usr/src/packages/BUILD/) mit denen im %buildroot-Verzeichnis.



Kommentare

Einen Kommentar hinzufügen



 Suchen:


 Umfrage

(Nur für angemeldete Benutzer)

Was wird hier am meisten vermisst?

[ Ergebnis | Umfragen ]

Stimmen: 621
Kommentare: 0

 Zitate

Bill Gates bei "Wetten, dass": "Ich wette, dass ich einhundert Windows- Fehlermeldungen an den Wutausbrüchen der Anwender erkennen kann!"

-- anonymous