/usr/share/doc/HOWTO/de-html/DE-RPM-HOWTO-7.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
 <META NAME="GENERATOR" CONTENT="LinuxDoc-Tools 0.9.65">
 <TITLE>Linux RPM HOWTO: RPM-Pakete erstellen</TITLE>
 <LINK HREF="DE-RPM-HOWTO-8.html" REL=next>
 <LINK HREF="DE-RPM-HOWTO-6.html" REL=previous>
 <LINK HREF="DE-RPM-HOWTO.html#toc7" REL=contents>
</HEAD>
<BODY>
<A HREF="DE-RPM-HOWTO-8.html"><IMG SRC="next.png" ALT="Weiter"></A>
<A HREF="DE-RPM-HOWTO-6.html"><IMG SRC="prev.png" ALT="Zurück"></A>
<A HREF="DE-RPM-HOWTO.html#toc7"><IMG SRC="toc.png" ALT="Inhalt"></A>
<HR>
<H2><A NAME="s7">7.</A> <A HREF="DE-RPM-HOWTO.html#toc7">RPM-Pakete erstellen</A></H2>

<P>Ein eigenes RPM-Paket zusammenzustellen ist recht einfach, insbesondere
wenn man die Software, die man in ein Paket zusammenpacken m&ouml;chte, dazu
bringen kann, ohne Eingriff eines Nutzers automatisch zu kompilieren.</P>
<P>Der grundlegende Ablauf beim Erstellen eines RPM-Paketes ist wie folgt:
<UL>
<LI>Sicherstellen, da&szlig; <CODE>/etc/rpmrc</CODE> f&uuml;r das System konfiguriert ist.</LI>
<LI>Der Sourcecode, der in das Paket soll, mu&szlig; auf dem eigenem System
korrekt kompilieren.</LI>
<LI>Einen Patch f&uuml;r alle Ver&auml;nderungen erstellen, die notwendig waren,
damit die Quellen korrekt &uuml;bersetzt wurden.</LI>
<LI>Erstellen einer Spec-Datei f&uuml;r das Paket.</LI>
<LI>Sicherstellen, da&szlig; alles da ist, wo es hingeh&ouml;rt.</LI>
<LI>Paket erstellen mit dem RPM.</LI>
</UL>
</P>
<P>Standardm&auml;&szlig;ig erzeugt der RPM sowohl Quell- als auch Bin&auml;rcode.</P>

<H2><A NAME="ss7.1">7.1</A> <A HREF="DE-RPM-HOWTO.html#toc7.1">Die Datei rpmrc</A>
</H2>

<P>Im Moment wird die Konfiguration des RPM ausschlie&szlig;lich &uuml;ber die Datei
<CODE>/etc/rpmrc</CODE> erledigt. Eine Beispieldatei k&ouml;nnte so aussehen:
<BLOCKQUOTE><CODE>
<PRE>
require_vendor: 1
distribution: Marke Eigenbau!
require_distribution: 1
topdir: /usr/src/meins
vendor: Mickiesoft
packager:  Mickeysoft Packaging Account &lt;packages@mickiesoft.com>

optflags: i386 -O2 -m486 -fno-strength-reduce
optflags: alpha -O2
optflags: sparc -O2

signature: pgp
pgp_name: Mickeysoft Packaging Account
pgp_path: /home/packages/.pgp

tmppath: /usr/tmp
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Die Zeile <CODE>require_vendor</CODE> veranla&szlig;t RPM dazu, eine Vendorzeile zu
verlangen. Diese kann dann sowohl in <CODE>/etc/rpmrc</CODE> als auch im Header
der Spec-Datei selbst festgelegt werden. Um dieses Feature abzuschalten,
wird es auf <CODE>0</CODE> gesetzt. Gleiches gilt f&uuml;r die Zeilen
<CODE>require_distribution</CODE> und <CODE>require_group</CODE>.</P>
<P>Die n&auml;chste Zeile ist die <CODE>distribution</CODE> Zeile. Diese kann entweder
hier oder erst sp&auml;ter im Header der Spec-Datei definiert werden. Wenn man
das Archiv f&uuml;r eine bestimmte Distribution zusammenstellt, ist es sinnvoll,
die Zeile entsprechend anzugeben, es ist jedoch nicht unbedingt
erforderlich. Die <CODE>vendor</CODE> Zeile ist &auml;hnlich, kann jedoch alles
m&ouml;gliche enthalten (z.B. Joe's Software and Rock Music Emporium).</P>
<P>RPM unterst&uuml;tzt jetzt auch das Packen von Archiven f&uuml;r verschiedene
Architekturen. Die Datei <CODE>rpmrc</CODE> kann ``optflags'' Variablen
beinhalten, die f&uuml;r einzelne Architekturen spezifische Flags f&uuml;r das
Kompilieren usw. enthalten. Die Verwendung dieser Variablen wird in einem
sp&auml;teren Abschnitt behandelt.</P>
<P>Zus&auml;tzlich zu den obigen Makros gibt es noch einige weitere. Man kann
<BLOCKQUOTE><CODE>
<PRE>
rpm --showrc
</PRE>
</CODE></BLOCKQUOTE>

benutzen, um herauszufinden, wie die Tags im Moment gesetzt sind und was
die verf&uuml;gbaren Flags sind.</P>

<H2><A NAME="ss7.2">7.2</A> <A HREF="DE-RPM-HOWTO.html#toc7.2">Die Spec-Datei</A>
</H2>

<P>Kommen wir jetzt zu den Spec-Dateien. Sie sind erforderlich, um ein Paket
zu erstellen. Sie enthalten eine Beschreibung der Software, Hinweise zum
&Uuml;bersetzen der selbigen und eine Dateiliste aller Binaries, die installiert
werden.</P>
<P>Man sollte die Spec-Datei nach der Standardkonvention benennen. Diese
lautet Paketname-Strich-Versionsnummer-Strich-Releasenummer-Punkt-spec.</P>
<P>Hier ein Beispiel f&uuml;r eine Spec-Datei (vim-3.0-1.spec):
<BLOCKQUOTE><CODE>
<PRE>
Summary: ejects ejectable media and controls auto ejection
Name: eject
Version: 1.4
Release: 3
Copyright: GPL
Group: Utilities/System
Source: sunsite.unc.edu:/pub/Linux/utils/disk-management/eject-1.4.tar.gz
Patch: eject-1.4-make.patch
Patch1: eject-1.4-jaz.patch
%description
This program allows the user to eject media that is autoejecting like
CD-ROMs, Jaz and Zip drives, and floppy drives on SPARC machines.

%prep
%setup
%patch -p1
%patch1 -p1

%build
make RPM_OPT_FLAGS="$RPM_OPT_FLAGS"

%install
install -s -m 755 -o 0 -g 0 eject /usr/bin/eject
install -m 644 -o 0 -g 0 eject.1 /usr/man/man1

%files
%doc README COPYING ChangeLog

/usr/bin/eject
/usr/man/man1/eject.1
</PRE>
</CODE></BLOCKQUOTE>

Die erl&auml;uternden Texte wie <CODE>%description</CODE> oder <CODE>Summary</CODE> sollten
sinnvollerweise in Englisch verfa&szlig;t werden, es sei denn, es handelt sich
um ein Paket, das nur f&uuml;r deutschsprachige Anwender gedacht ist.</P>

<H2><A NAME="ss7.3">7.3</A> <A HREF="DE-RPM-HOWTO.html#toc7.3">Der Header</A>
</H2>

<P>Der Header hat einige Standardfelder, die angegeben werden m&uuml;ssen. Es gibt
auch ein paar kleine "Problemzonen", die man kennen sollte. Die Felder
haben folgenden Inhalt:
<UL>
<LI><CODE>Summary:</CODE> Kurze Beschreibung des Paketes (eine Zeile)</LI>
<LI><CODE>Name:</CODE> Namensstring aus dem Dateinamen, den das
RPM-Paket erhalten soll</LI>
<LI><CODE>Version:</CODE> Versionsstring aus dem Dateinamen, den das
RPM-Paket erhalten soll</LI>
<LI><CODE>Release:</CODE> Releasenummer f&uuml;r Pakete gleicher Version
(d.h. wenn man nach dem Zusammenpacken und Ver&ouml;ffenlichen seines Paketes
feststellt, da&szlig; es doch noch den einen oder anderen kleineren Bug enth&auml;lt,
bekommt die neue Ausgabe nur eine neue, um eins h&ouml;here Releasenummer)</LI>
<LI><CODE>Icon:</CODE> Name der Icondatei, die von anderen
Highlevel-Installationstools verwendet wird (wie z.B. Red Hat's ``glint'').
Es mu&szlig; ein Gif sein, und sich im SOURCES-Verzeichnis befinden.</LI>
<LI><CODE>Source:</CODE> Diese Zeile verweist auf die Stelle, von der die
originalen Quellen stammen. Diese kann man dann verwenden, wenn man
einmal das urspr&uuml;nglichen Paket haben will, oder nach neueren Versionen
sucht. Nachteil: Der Dateiname in dieser Zeile mu&szlig; dem Dateinamen auf
dem eigenen System entsprechen, d.h. man sollte das heruntergeladene Archiv
nicht umbenennen. Man kann auch mehrere Quelldateien mit mehreren
Zeilen wie hier angeben:
<BLOCKQUOTE><CODE>
<PRE>
Source0: ftp://sunsite.unc.edu/pub/foo/bar/blah-0.tar.gz
Source1: ftp://sunsite.unc.edu/pub/foo/bar/blah-1.tar.gz
Source2: ftp://sunsite.unc.edu/pub/foo/bar1/fooblah.tar.gz
</PRE>
</CODE></BLOCKQUOTE>

Diese Dateien w&uuml;rden im <CODE>SOURCES</CODE> Verzeichnis gespeichert werden.
Die Verzeichnisstruktur wird in einem sp&auml;teren Abschnitt diskutiert:
"Die Struktur der Quellenverzeichnisse".</LI>
<LI><CODE>Patch:</CODE> Die Stelle, von der man den Patch wenn n&ouml;tig
herunterladen kann. Bedingung: Der Dateiname mu&szlig; hier dem Namen
entsprechen, der benutzt wird, wenn man den Patch SELBST anwendet.
Auch hier kann man wieder mehrere Patchdateien angeben:
<BLOCKQUOTE><CODE>
<PRE>
Patch0: ftp://sunsite.unc.edu/pub/foo/bar/blah-0.patch
Patch1: ftp://sunsite.unc.edu/pub/foo/bar/blah-1.patch
Patch2: ftp://sunsite.unc.edu/pub/foo/bar1/fooblah.patch
</PRE>
</CODE></BLOCKQUOTE>

Diese Dateien werden auch im <CODE>SOURCES</CODE> Verzeichnis gespeichert.</LI>
<LI><CODE>Copyright:</CODE> Das Copyright des Paketes. Hier sollte etwas
von der Art GPL, BSD, MIT, public domain, distributable, oder commercial
stehen.</LI>
<LI><CODE>BuildRoot:</CODE> Hier kann ein Verzeichnis festgelegt
werden, welches als ``root''-Verzeichnis f&uuml;r die &Uuml;bersetzung und
Installation des Paketes dient. Man kann diese M&ouml;glichkeit einsetzen, um
ein Paket erst zu testen, bevor man es endg&uuml;ltig auf dem Rechner
installiert.</LI>
<LI><CODE>Group:</CODE> Diese Zeile teilt einem 
Highlevel-Installationsprogram ,wie z.B. Red Hat's ``glint'', mit, wo in
der Pakethierarchie es einzuordnen ist. Der Groups-Baum sieht zur Zeit
etwa so aus:
<BLOCKQUOTE><CODE>
<PRE>
Applications
    Communications
    Editors
        Emacs
    Engineering
    Spreadsheets
    Databases
    Graphics
    Networking
    Mail
    Math
    News
    Publishing
        TeX
Base
    Kernel
Utilities
    Archiving
    Console
    File
    System
    Terminal
    Text
Daemons
Documentation
X11
    XFree86
        Servers
    Applications
        Graphics
        Networking
    Games
        Strategy
        Video
    Amusements
    Utilities
    Libraries
    Window Managers
Libraries
Networking
    Admin
    Daemons
    News
    Utilities
Development
    Debuggers
    Libraries
        Libc
    Languages
        Fortran
        Tcl
    Building
    Version Control
    Tools
Shells
Games
</PRE>
</CODE></BLOCKQUOTE>
</LI>
<LI><CODE>%description</CODE> Dies ist kein direkter Teil des Headers,
wird aber trotzdem hier kurz mit erw&auml;hnt. Dies ist ein mehrzeiliges Feld,
und sollte eine kurze Beschreibung des Paketes geben. Man ben&ouml;tigt einen
Punkt Beschreibung pro Paket und/oder Unterpaket. </LI>
</UL>
</P>

<H2><A NAME="ss7.4">7.4</A> <A HREF="DE-RPM-HOWTO.html#toc7.4">Prep</A>
</H2>

<P>Das ist der zweite Abschnitt in der Spec-Datei. Hiermit werden die Quellen
f&uuml;rs &Uuml;bersetzen angepa&szlig;t. Man sollte hier alle Dinge veranlassen, die
n&ouml;tig sind, um die Quellen zu patchen und f&uuml;r ein <CODE>make</CODE> vorzubereiten.</P>
<P>Anmerkung: Jeder dieser Abschnitte ist eigentlich nur ein Platz, an dem
Shellskripte ausgef&uuml;hrt werden. Man k&ouml;nnte einfach ein Shellskript
schreiben, das nach dem <CODE>%prep</CODE> Tag eingetragen wird und
die Quellen entpackt und patcht. Wir haben jedoch Makros geschrieben,
die das ein wenig vereinfachen sollen.</P>
<P>Das erste dieser Makros ist das <CODE>%setup</CODE> Makro. Im einfachsten
Fall (keine Parameter auf der Kommandozeile) entpackt es nur die
Quellen und macht ein <CODE>cd</CODE> ins Quellverzeichnis.
Es versteht die folgenden Optionen:
<UL>
<LI><CODE>-n name</CODE> setzt den Namen des &Uuml;bersetzungsverzeichnisses
auf den angegebenen Namen <CODE>name</CODE>. Der Defaultwert ist 
<CODE>$NAME-$VERSION</CODE>. Andere M&ouml;glichkeiten sind
<CODE>$NAME</CODE>, <CODE>${NAME}${VERSION}</CODE> oder was immer das
Haupttararchiv enth&auml;lt. (Man beachte, da&szlig; die hier genannten ``$''
Variablen <EM>keine</EM> echten Variablen, die im Specfile zur Verf&uuml;gung
stehen, sind, sondern nur als Platzhalter anstelle von Beispielnamen stehen. Man
mu&szlig; die echten Namen und Versionen der Pakete einsetzen, keine Variablen.)</LI>
<LI><CODE>-c</CODE> erstellt und wechselt in das angegebene Verzeichnis
<EM>vor</EM> dem Entpacken.</LI>
<LI><CODE>-b #</CODE> entpackt Source# <EM>vor</EM> dem Wechseln in
das Verzeichnis (nicht in Verbindung mit <CODE>-c</CODE> verwenden). Diese Option
ist nur sinnvoll f&uuml;r mehrere Quelldateien.</LI>
<LI><CODE>-a #</CODE> entpackt Source# <EM>nach</EM> dem Wechseln in
das Verzeichnis.</LI>
<LI><CODE>-T</CODE> Diese Option verhindert die Default-Aktion des
Entpackens der Quellen und erfordert ein <CODE>-b 0</CODE> oder <CODE>-a 0</CODE> um die
Hauptquelldatei zu entpacken. Das wird ben&ouml;tigt, wenn es noch andere
Quellen gibt.</LI>
<LI><CODE>-D</CODE> Das Verzeichnis <EM>nicht</EM> vor dem Entpacken l&ouml;schen.
Das ist nur sinnvoll, wenn man mehr als ein Setup-Makro hat. Die Option
sollte <EM>nur</EM> in Setup-Makros <EM>nach</EM> dem ersten Makro benutzt werden,
aber nie im ersten.</LI>
</UL>
</P>
<P>Das n&auml;chste verf&uuml;gbare Makro ist das <CODE>%patch</CODE> Makro. Dieses Makro
erleichtert das Anwenden von Patches auf die Quellen. Es kennt die
folgenden Optionen
<UL>
<LI><CODE>#</CODE> verwendet Patch# als Patchfile.</LI>
<LI><CODE>-p #</CODE> gibt die Anzahl der Verzeichnisse an, die f&uuml;r
das patch(1) Kommando vom Pfad (siehe auch Man-Page von <CODE>patch</CODE>)entfernt
werden.</LI>
<LI><CODE>-pN</CODE> F&uuml;hrt ein <CODE>patch -pN &lt; $RPM_SOURCE_DIR/patchname/</CODE> aus, wobei patchname der Name des Patches aus der <CODE>Patch</CODE>-Zeile im
Header ist. Diese Option ist n&uuml;tzlich f&uuml;r die Anwendung weiterer Patches,
wenn f&uuml;r diese eine andere Anzahl von Verzeichnissen vom Pfad entfernt
werden mu&szlig; als f&uuml;r das erste Makro.</LI>
<LI><CODE>%patch#</CODE> ist an Stelle des richtigen Kommandos
<CODE>%patch # -pN</CODE> auch m&ouml;glich</LI>
</UL>
</P>
<P>Das sollten alle Makros sein, die man ben&ouml;tigt. Wenn man diese richtig
verstanden hat, kann man auch andere Arten von Setup's via
<CODE>sh</CODE>-Skripten erstellen. Alles was bis zum <CODE>%build</CODE> Makro,
n&auml;her erl&auml;utert im n&auml;chsten Abschnitt, eingef&uuml;gt wird, wird von der
<CODE>sh</CODE> abgearbeitet. Siehe das Beispiel oben f&uuml;r Aktionen, die hier
ausgef&uuml;hrt werden k&ouml;nnen.</P>

<H2><A NAME="ss7.5">7.5</A> <A HREF="DE-RPM-HOWTO.html#toc7.5">Build</A>
</H2>

<P>F&uuml;r diesen Abschnitt gibt es keine eigenen Makros. Hier werden alle
Kommandos eingetragen, die notwendig sind, um ein Programm zu &uuml;bersetzen,
nachdem die Quellen entpackt und gepacht wurden und man ins entsprechende
Verzeichnis gewechselt hat. Auch dies hier ist wieder nur eine Folge von
Anweisungen, die der <CODE>sh</CODE>zur Ausf&uuml;hrung &uuml;bergeben werden, d.h. alle
g&uuml;ltigen <CODE>sh</CODE>-Kommandos k&ouml;nnen hier benutzt werden, inklusive
Kommentare. <B>Das aktuelle Verzeichnis wird nach jedem dieser Abschnitte
wieder auf das Toplevel-Verzeichnis der Quellen gesetzt</B>, man sollte das
immer beachten. Man kann, wenn notwendig, in ein Unterverzeichnis wechseln.</P>

<H2><A NAME="ss7.6">7.6</A> <A HREF="DE-RPM-HOWTO.html#toc7.6">Install</A>
</H2>

<P>Auch f&uuml;r diesen Abschnitt gibt es keine eigenen Makros. Es werden hier
ebenfalls alle Kommandos aufgelistet, die notwendig sind, um das fertige
Programm zu installieren. Falls das Paket ein <CODE>make install</CODE> hat, kann
man es hier einsetzen. Wenn nicht, kann das Makefile entsprechend
gepatcht werden, oder die Installation von Hand mit Shellkommandos
bewerkstelligt werden. Das aktuelle Verzeichnis ist hier wieder das
Toplevel-Verzeichnis der Quellen.</P>

<H2><A NAME="ss7.7">7.7</A> <A HREF="DE-RPM-HOWTO.html#toc7.7">Optionale Pre- und Postinstall/deinstall Skripten</A>
</H2>

<P>Hier k&ouml;nnen Skripten angegeben werden, die vor und nach der Installation
und der Deinstallation von fertig &uuml;bersetzten Paketen abgearbeitet werden.
Einer der Hauptgr&uuml;nde daf&uuml;r ist das Ausf&uuml;hren von speziellen Programmen,
wie z.B. <CODE>ldconfig</CODE> nach dem Installieren oder Entfernen von Paketen
mit Shared Libraries. Die Makros f&uuml;r die jeweiligen Skripte sind:
<UL>
<LI><CODE>%pre</CODE> ist das Makro zum Ausf&uuml;hren von Pre-Install
Skripten.</LI>
<LI><CODE>%post</CODE> ist das Makro zum Ausf&uuml;hren von Post-Install
Skripten.</LI>
<LI><CODE>%preun</CODE> ist das Makro zum Ausf&uuml;hren von Pre-Deinstall
Skripten.</LI>
<LI><CODE>%postun</CODE> ist das Makro zum Ausf&uuml;hren von Post-Deinstall
Skripten.</LI>
</UL>
</P>
<P>Der Inhalt dieser Abschnitte ist ein beliebiges <CODE>sh</CODE>-Skript, jedoch
<EM>ohne</EM> die <CODE>#!/bin/sh</CODE> Zeile.</P>

<H2><A NAME="ss7.8">7.8</A> <A HREF="DE-RPM-HOWTO.html#toc7.8">Files</A>
</H2>

<P>In diesem Abschnitt <EM>m&uuml;ssen</EM> die Dateien des fertig &uuml;bersetzten Paketes
angegeben werden. RPM hat keine M&ouml;glichkeit, herauszufinden, welche Dateien
als Ergebnis eines <CODE>make install</CODE> im System installiert werden. Hierf&uuml;r
gibt es <EM>KEINE</EM> M&ouml;glichkeit. Es gab Vorschl&auml;ge, dieses mit einem
<CODE>find</CODE> vor und nach dem Installieren zu bewerkstelligen. In einem
Multiusersystem, bei dem zur gleichen Zeit von anderen Prozessen Dateien
geschaffen werden k&ouml;nnen, die mit dem Paket nichts zu tun haben, ist dies
jedoch nicht sinnvoll.</P>
<P>Hier gibt es ebenfalls einige Makros f&uuml;r spezielle Zwecke. Folgende Makros
stehen zur Verf&uuml;gung:
<UL>
<LI><CODE>%doc</CODE> bezeichnet Dokumentation aus dem Quellpaket, die
zusammen mit den &uuml;bersetzten Bin&auml;rpaketen installiert werden soll. Sie wird
in <CODE>/usr/doc/$NAME-$VERSION-$RELEASE</CODE> installiert.
Man kann mehrere Dokumente auf einer Kommandozeile auflisten oder je eins
pro separatem Makro.</LI>
<LI><CODE>%config</CODE> bezeichnet Konfigurationsdateien aus dem Paket.
Dies beinhaltet z.B. Dateien wie sendmail.cf, passwd usw. Wenn man sp&auml;ter
das Paket deinstalliert, werden unver&auml;nderte Kofigurationsdateien mit dem
Paket gel&ouml;scht und ver&auml;nderte mit einem angeh&auml;ngten <CODE>.rpmsave</CODE> gesichert.
Auch hier k&ouml;nnen einem Makro mehrere Dateien &uuml;bergeben werden.</LI>
<LI><CODE>%dir</CODE> bezeichnet ein Verzeichnis in einer Dateiliste,
welches komplett mit zum Paket geh&ouml;rt. Normalerweise wird ein Verzeichnis,
das <EM>OHNE</EM> ein <CODE>%dir</CODE> Makro aufgef&uuml;hrt wird, zusammen mit
seinem <EM>KOMPLETTEN</EM> Inhalt in die Dateiliste aufgenommen und sp&auml;ter mit
dem Paket zusammen installiert.</LI>
<LI><CODE>%files -f &lt;filename&gt;</CODE> erm&ouml;glicht das Auflisten der
zugeh&ouml;rigen Dateien in einer beliebigen anderen Datei im
&Uuml;bersetzungsverzeichnis der Quellen. Das ist sinnvoll, wenn man ein Paket
hat, das seine eigene Dateiliste zusammenstellen kann. Man kann diese
Liste dann hier angeben, und mu&szlig; sie dann nicht extra hier einf&uuml;gen.</LI>
</UL>
</P>
<P>Das gr&ouml;&szlig;te Problem der Dateilisten ist das Auflisten von Verzeichnissen.
Wenn man aus Versehen <CODE>/usr/bin</CODE> mit auflistet, werden <EM>alle</EM>
Dateien in <CODE>/usr/bin</CODE> des Systems als zum Paket geh&ouml;rig betrachtet.
.</P>
<H2><A NAME="ss7.9">7.9</A> <A HREF="DE-RPM-HOWTO.html#toc7.9">&Uuml;bersetzen</A>
</H2>


<H3>Die Struktur der Quellenverzeichnisse</H3>

<P>Zun&auml;chst braucht man nat&uuml;rlich einen passenden Verzeichnisbaum f&uuml;r
die Quelldateien. Man kann diesen in der Datei <CODE>/etc/rpmrc</CODE>
festlegen, &uuml;blicherweise wird hier einfach <CODE>/usr/src</CODE> verwendet.</P>
<P>Eventuell m&uuml;ssen die folgenden Verzeichnisse angelegt werden, um einen
Verzeichnisbaum f&uuml;r das &Uuml;bersetzen zu erstellen:
<UL>
<LI><CODE>BUILD</CODE> ist das Verzeichnis, in dem die &Uuml;bersetzung durch den RPM
stattfindet. Man mu&szlig; seine Test&uuml;bersetzungen nicht in diesem speziellen
Verzeichnis durchf&uuml;hren, aber hier ist es, wo der RPM <EM>seine</EM>
&Uuml;bersetzungen durchf&uuml;hrt.</LI>
<LI><CODE>SOURCES</CODE> hier sollten alle tar-Archive der originalen Quellen
und die Patches stehen. Hier sucht der RPM per Default nach den
Quelldateien.</LI>
<LI><CODE>SPECS</CODE> hier geh&ouml;ren die Spec-Dateien hin.</LI>
<LI><CODE>RPMS</CODE> das Verzeichnis f&uuml;r die fertig &uuml;bersetzten rpm's.</LI>
<LI><CODE>SRPMS</CODE> das Verzeichnis f&uuml;r die Quell-rpm's.</LI>
</UL>
</P>

<H3>Test&uuml;bersetzung</H3>

<P>Zun&auml;chst sollte man daf&uuml;r sorgen, da&szlig; die Quellen korrekt ohne den RPM
&uuml;bersetzt werden. Dazu entpackt man die Quellen und benennt das
Verzeichnis um nach $NAME.orig. Danach werden die Quellen ein
zweites Mal entpackt. Diese zweite Version wird dann zum &Uuml;bersetzen
benutzt. Man wechselt ins Quellverzeichnis und folgt den Anweisungen zum
&Uuml;bersetzen des Paketes. Wenn man, um die Quellen zu &uuml;bersetzen, &Auml;nderungen
an ihnen vornehmen mu&szlig;te, braucht man ein Patch. Um einen solchen zu
erstellen, entfernt man alle Dateien, die von einem <CODE>configure</CODE> Skript
o.&auml;. angelegt wurden, aus dem Verzeichnis, das die jetzt vollst&auml;ndig
&uuml;bersetzbaren Quellen enth&auml;lt. Danach wechselt man in das &uuml;bergeordnete
Verzeichnis des obersten Quellverzeichnisses. Danach wird der Patch
erstellt mit
<BLOCKQUOTE><CODE>
<PRE>
diff -uNr verzname.orig verzname > ../SOURCES/dirname-linux.patch
</PRE>
</CODE></BLOCKQUOTE>

o.&auml;., je nach konkretem Fall.
Das erzeugt einen Patch, der in der Spec-Datei verwendet werden kann. Der
``linux'' Teil des Patchnamens ist hier nur als Beispiel, man kann hier
einen Namen verwenden, der etwas mehr &uuml;ber den <EM>Grund</EM> f&uuml;r diesen Patch
aussagt, z.B. ``config'' oder ``bugs''. Man sollte au&szlig;erdem noch einen
Blick in die fertige Patchdatei werfen, um sicherzustellen, da&szlig; nicht aus
Versehen Binaries o.&auml;. mit eingetragen wurden.</P>

<H3>Erstellen der Dateiliste</H3>

<P>Nachdem man funktionierende Quellen hat, werden diese &uuml;bersetzt und
installiert, so wie es beim Endbenutzer geschehen w&uuml;rde. Aus dem Resultat
dieser Installation wird dann die Dateiliste erstellt. Wir erstellen die
Spec-Datei normalerweise gleichzeitig mit den beschriebenen Schritten. Man
erstellt eine Startversion der Datei und setzt die einfachen Teile ein, und
erg&auml;nzt dann nach und nach die anderen Teile im weiteren Verlauf.</P>

<H3>Erstellen des Paketes mit dem RPM</H3>

<P>Wenn die Spec-Datei fertig ist, kann man versuchen, ein RPM-Paket zu
erzeugen. Dies geschieht meistens mit einem</P>
<P>
<BLOCKQUOTE><CODE>
<PRE>
rpm -ba foobar-1.0.spec
</PRE>
</CODE></BLOCKQUOTE>
</P>
<P>Es gibt weitere Optionen, die mit dem <CODE>-b</CODE> Switch zusammen n&uuml;tzlich sind:
<UL>
<LI><CODE>p</CODE> Ausf&uuml;hren des <CODE>prep</CODE> Abschnittes der Spec-Datei.</LI>
<LI><CODE>l</CODE> ist ein Listencheck, der einige Tests mit <CODE>%files</CODE> macht.</LI>
<LI><CODE>c</CODE> Ausf&uuml;hren von prep und kompilieren. Kann verwendet werden, um zu
testen, ob die Quellen auch wirklich durchkompilieren. Das sieht auf den
ersten Blick etwas sinnlos aus, da man seine Quellen &uuml;blicherweise erst
zum &Uuml;bersetzen bringt und dann erst den RPM anwirft, aber wenn man erst
mit dem RPM vertraut ist, gibt es Gelegenheiten, in denen das sinnvoll
ist.</LI>
<LI><CODE>i</CODE> Ausf&uuml;hren von prep, kompilieren, installieren.</LI>
<LI><CODE>b</CODE> Ausf&uuml;hren von prep, kompilieren, installieren, erstellen nur
des Bin&auml;rpaketes.</LI>
<LI><CODE>a</CODE> alles erstellen (Quell- und Bin&auml;rpakete).</LI>
</UL>

Es gibt noch einige Optionen zum Modifizieren des Ablaufs des
<CODE>-b</CODE>-Switch:
<UL>
<LI><CODE>--short-circuit</CODE> beginnt direkt mit dem angegebenen Abschnitt
(nur zusammen mit c und i).</LI>
<LI><CODE>--clean</CODE> entfernt nach Beendigung die &Uuml;bersetzungsverzeichnisse.</LI>
<LI><CODE>--keep-temps</CODE> beh&auml;lt alle tempor&auml;ren Dateien und Skripte, die in
/tmp angelegt wurden. Mit der Option <CODE>-v</CODE> kann man sehen, was in /tmp
erzeugt wurde.</LI>
<LI><CODE>--test</CODE> f&uuml;hrt keine wirklichen Aktionen aus, aber bewahrt
temp-Dateien.</LI>
</UL>
</P>

<H2><A NAME="ss7.10">7.10</A> <A HREF="DE-RPM-HOWTO.html#toc7.10">Austesten</A>
</H2>

<P>Wenn man ein fertiges Paket f&uuml;r die Quellen und die Binaries hat, sollte
man es testen. Das Beste und Einfachste ist es, das Paket auf einem v&ouml;llig
anderen Rechner zu testen als dem, auf dem man es erstellt hat.
Schlie&szlig;lich hat man das Paket bereits mehrfach auf diesem Rechner mit
<CODE>make install</CODE> o.&auml;. installiert, so das es nun bereits recht gut
installiert sein sollte.</P>
<P>Man kann das Paket mit <CODE>rpm -u packagename</CODE> zwar wieder deinstallieren,
wenn man aber in der Liste der Dateien eine oder mehrere vergessenen hat,
die aber durch das <CODE>make install</CODE> installiert wurden, werden diese
nicht wieder deinstalliert. Wenn man danach das Paket wieder installiert,
ist es wieder vollst&auml;ndig auf dem Rechner, auch wenn das rpm selbst
unvollst&auml;ndig ist.
Dar&uuml;ber hinaus sollte man beachten, da&szlig; man selbst zwar eine
Testinstallation mit <CODE>rpm -ba package</CODE> macht, die meisten Leute jedoch
nur ein <CODE>rpm -i package</CODE> machen werden. Man mu&szlig; daher darauf achten,
da&szlig; in den <CODE>build</CODE> oder <CODE>install</CODE> Abschnitten nichts getan wird, was
auch f&uuml;r eine reine Installation der Binaries notwendig ist.</P>



<H2><A NAME="ss7.11">7.11</A> <A HREF="DE-RPM-HOWTO.html#toc7.11">Wenn das neue rpm fertig ist</A>
</H2>

<P> Wenn man ein neues rpm von irgend etwas fertiggestellt hat, kann man
es - unter der Voraussetzung, da&szlig; es noch nicht als rpm existiert - anderen
zur Verf&uuml;gung stellen. Hierbei mu&szlig; das, was man zusammengepackt hat,
nat&uuml;rlich ein entsprechendes Copyright haben. Man kann es dann auf den
FTP-Server <CODE>
<A HREF="ftp://ftp.redhat.com">ftp.redhat.com</A></CODE> stellen.</P>

<H2><A NAME="ss7.12">7.12</A> <A HREF="DE-RPM-HOWTO.html#toc7.12">Was weiter?</A>
</H2>

<P>Es sei hier noch einmal besonders auf die vorhergehenden Abschnitte zum
Testen und der Verwendung der fertigen rpm's hingewiesen. Wir wollen so
viele rpm's wie m&ouml;glich in guter Qualit&auml;t zur Verf&uuml;gung stellen.
Bitte die rpm's gr&uuml;ndlich austesten und dann zum Nutzen aller ins Netz
stellen. <EM>Unbedingt</EM> sollte man jedoch vorher sicherstellen, da&szlig; das
Copyright dieses auch <EM>zul&auml;&szlig;t</EM>. Kommerzielle Software und Shareware
sollte nicht &ouml;ffentlich zur Verf&uuml;gung gestellt werden, es sei denn, das
Copyright der entsprechenden Software l&auml;&szlig;t das ausdr&uuml;cklich zu. Das gilt
z.B. f&uuml;r Programme wie Netscape, ssh, pgp, usw.</P>

<HR>
<A HREF="DE-RPM-HOWTO-8.html"><IMG SRC="next.png" ALT="Weiter"></A>
<A HREF="DE-RPM-HOWTO-6.html"><IMG SRC="prev.png" ALT="Zurück"></A>
<A HREF="DE-RPM-HOWTO.html#toc7"><IMG SRC="toc.png" ALT="Inhalt"></A>
</BODY>
</HTML>
doc-linux-de 2003.10-5 / usr / share / doc / HOWTO / de-html / DE-RPM-HOWTO-7.html
