  Linux RPM HOWTO
  Donnie Barnes (djb@redhat.com) und Tilo Wenzel
  v2.0.1-2, 25. September 1997

  In diesem HOWTO wird beschrieben, wie man den Red Hat Packagemanager
  rpm anwendet und eigene Pakete erstellt.


  1.  Copyright

  1.1.  Copyright der englischen Version

  Dieses Dokument und sein Inhalt sind durch Copyright geschtzt. Die
  Weiterverbreitung dieses Dokuments ist so lange gestattet, wie der
  Inhalt vollstndig und unverndert bleibt. Das heit, es ist nur ein
  Neuformatieren, Neuausdrucken oder Weiterverteilen erlaubt. Da die
  deutsche Version ein von der englischen Version abgeleitetes Werk ist,
  unterliegt sie demselben Copyright.


  1.2.  Bemerkungen zur deutschen bersetzung


  Dieses Dokument ist die deutsche bersetzung des englischen Originals
  von Donnie Barnes. In der deutschen bersetzung wurden mit Zustimmung
  des Autors des Originals ein paar Korrekturen und nderungen vom
  bersetzer Tilo Wenzel vorgenommen, die das Eine oder Andere
  hoffentlich etwas klarer machen.


  2.  Einfhrung

  RPM ist der Red Hat Package Manager. Obwohl der Name die Bezeichnung
  Red Hat enthlt, ist er dennoch als ein vollstndig offenes System
  angelegt, welches jeder benutzen kann. Es gibt dem Benutzer die
  Mglichkeit, aus dem Quellcode fr eine neue Software Pakete mit
  Quell- und Binrcode zu erstellen, mit denen es mglich ist, Binaries
  einfach zu installieren und zu verwalten sowie Quellcode einfach zu
  bersetzen. Er besitzt auch eine eigene Datenbank mit Informationen
  ber alle Pakete und deren zugehrige Dateien, die zum Testen von
  Paketen und zum Abfragen von Informationen bezglich Dateien und/oder
  Paketen benutzt werden kann.

  Red Hat Software erlaubt es anderen Herstellern von Distributionen
  ausdrcklich, den Paketmanager auszutesten und ihn fr den Aufbau der
  eigenen Distributionen einzusetzen. RPM ist sehr flexibel und einfach
  zu benutzen, obwohl es die Grundlage fr ein komplexes und groes
  System darstellt. Es ist darber hinaus vollstndig offen und fr
  jeden verfgbar, wir wrden uns jedoch ber Berichte bezglich Fehler
  und deren Beseitigung freuen. Die Benutzung und Verbreitung des RPM
  wird lizenzfrei unter der GPL gewhrt.

  Eine ausfhrlichere Dokumentation bezglich des RPM ist mit dem Buch
  Maximum RPM von Ed Bailey verfgbar. Dieses Buch steht zum
  Herunterladen oder zum Kauf auf http://www.redhat.com zur Verfgung.


  3.  bersicht

  Zunchst einige Worte ber die Philosophie, die hinter dem RPM steht.
  Eines der Ziele des RPM war die Mglichkeit der Verwendung der
  ursprnglichen Quellen. Fr den RPP (unser altes Paketsystem, aus dem
  sich kein Teil des RPM herleitet) waren die Quellpakete die gepatchten
  Quellen, aus denen wir die fertigen Pakete herstellten. Im Prinzip
  konnte man ein Quell-RPP installieren und es anschlieend ohne weitere
  Probleme mit make bersetzen. Aber die Quellen waren nicht mehr die
  Originale, und es gab keinen Hinweis darauf, was wir fr nderungen
  hatten vornehmen mssen, um es zum Laufen zu bringen. Die
  Originalquellen muten separat heruntergeladen werden. Mit RPM hat man
  sowohl die Originalquellen als auch den Patch, von dem kompiliert
  wurde.  Unserer Meinung nach ist das aus verschiedenen Grnden ein
  groer Vorteil.  Wenn  z.B. eine neue Version eines Programmes
  herauskommt, ist es nicht mehr ntig, noch einmal komplett von vorne
  anzufangen, um es unter RHL (Red Head Linux) zu kompilieren. Man kann
  sich den Patch anschauen, um zu sehen, was eventuell zu ndern ist.
  Alle einzukompilierenden Defaults usw. sind so einfach herauszufinden.
  RPM hat ebenfalls einen leistungsfhigen Abfragemechanismus. Man kann
  die gesamte Paketdatenbank nach bestimmten Paketen oder einzelnen
  Dateien durchsuchen und so einfach feststellen, zu welchem Paket eine
  Datei gehrt und wo sie herkommt. Die RPM-Dateien selbst sind
  komprimierte Archive, die einzelnen Pakete knnen jedoch einfach und
  schnell nach bestimmten Informationen durchsucht werden, da ein
  spezieller Header im Binrformat an jedes Paket angefgt wird. Dieser
  Header ist unkomprimiert und enthlt alle wichtigen Informationen. Das
  ermglicht das schnelle Durchsuchen von Paketen.

  Eine andere ntzliche Funktion ist die Mglichkeit, Pakete zu
  berprfen.  Falls man vermutet, da man ein fr ein Paket wichtiges
  File gelscht haben knnte, kann man dieses damit einfach
  kontrollieren. Man wird dann ber Probleme mit der gegenwrtigen
  Konfiguration informiert und kann falls notwendig das Paket neu
  installieren. Konfigurationsdateien werden, soweit vorhanden, nicht
  berschrieben.

  Wir mchten den Leuten von der Bogusdistribution fr viele ihrer Ideen
  und Konzepte danken, die im RPM enthalten sind. Obwohl der RPM
  vollstndig von Red Hat Software geschrieben wurde, basiert er doch
  auf von BOGUS geschriebenem Code (PM and PMS).


  4.  Allgemeine Informationen


  4.1.  Quellen fr den RPM

  Die beste Mglichkeit, den RPM zu installieren, ist natrlich, Red Hat
  Linux zu installieren. Wenn man das nicht will, kann man sich den RPM
  separat besorgen. Er ist von ftp.redhat.com zu bekommen.

  4.2.  Voraussetzungen fr den RPM

  Die Hauptvoraussetzung, um den RPM benutzen zu knnen, ist cpio 2.4.2
  oder grer. Obwohl das System primr fr den Einsatz unter Linux
  gedacht ist, ist es wahrscheinlich auch auf die meisten anderen UNIX-
  Systeme portierbar.  Bisher wurde es schon auf SunOS, Solaris, AIX,
  Irix, AmigaOS und anderen Systemen bersetzt. Die Binrpakete sind
  jedoch zwischen den verschiedenen Unixtypen nicht kompatibel!

  Das sind die minimalen Voraussetzungen fr die Installation des RPM.
  Um den RPM aus den Quellen selbst zu kompilieren, braucht man auch
  noch die blichen Dinge, die zum bersetzen notwendig sind, d.h. gcc,
  make, usw.


  5.  Benutzung des RPM

  Die einfachste Mglichkeit der Anwendung ist die Installation eines
  Paketes:



       rpm -i foobar-1.0-1.i386.rpm




  Ebenso einfach ist die Deinstallation eines Paketes:



       rpm -e foobar

  Ein etwas komplizierteres, aber sehr ntzliches Kommando erlaubt die
  Installation von Paketen via FTP. Wenn man eine Verbindung ins
  Internet hat und ein neues Paket installieren will, mu man die
  Dateien nur zustzlich mit einem gltigen URL versehen, etwa so:


       rpm -i ftp://ftp.pht.com/pub/linux/redhat/rh-2.0-beta/RPMS/foobar-1.0-1.i386.rpm




  Man beachte, da der RPM jetzt via FTP arbeitet und installiert.

  Auer fr diese simplen Kommandos kann rpm auch noch fr viele andere
  Aufgaben eingesetzt werden, wie dies die Usage Message andeutet:


       RPM version 2.3.9
       Copyright (C) 1997 - Red Hat Software
       This may be freely redistributed under the terms of the GNU Public License

       usage: rpm {--help}
              rpm {--version}
              rpm {--initdb}   [--dbpath <dir>]
              rpm {--install -i} [-v] [--hash -h] [--percent] [--force] [--test]
                               [--replacepkgs] [--replacefiles] [--root <dir>]
                               [--excludedocs] [--includedocs] [--noscripts]
                               [--rcfile <file>] [--ignorearch] [--dbpath <dir>]
                               [--prefix <dir>] [--ignoreos] [--nodeps]
                               [--ftpproxy <host>] [--ftpport <port>]
                               file1.rpm ... fileN.rpm
              rpm {--upgrade -U} [-v] [--hash -h] [--percent] [--force] [--test]
                               [--oldpackage] [--root <dir>] [--noscripts]
                               [--excludedocs] [--includedocs] [--rcfile <file>]
                               [--ignorearch]  [--dbpath <dir>] [--prefix <dir>]
                               [--ftpproxy <host>] [--ftpport <port>]
                               [--ignoreos] [--nodeps] file1.rpm ... fileN.rpm
              rpm {--query -q} [-afpg] [-i] [-l] [-s] [-d] [-c] [-v] [-R]
                               [--scripts] [--root <dir>] [--rcfile <file>]
                               [--whatprovides] [--whatrequires] [--requires]
                               [--ftpuseport] [--ftpproxy <host>] [--ftpport <port>]
                               [--provides] [--dump] [--dbpath <dir>] [targets]
              rpm {--verify -V -y} [-afpg] [--root <dir>] [--rcfile <file>]
                               [--dbpath <dir>] [--nodeps] [--nofiles] [--noscripts]
                               [--nomd5] [targets]
              rpm {--setperms} [-afpg] [target]
              rpm {--setugids} [-afpg] [target]
              rpm {--erase -e} [--root <dir>] [--noscripts] [--rcfile <file>]
                               [--dbpath <dir>] [--nodeps] [--allmatches]
                               package1 ... packageN
              rpm {-b|t}[plciba] [-v] [--short-circuit] [--clean] [--rcfile  <file>]
                               [--sign] [--test] [--timecheck <s>] specfile
              rpm {--rebuild} [--rcfile <file>] [-v] source1.rpm ... sourceN.rpm
              rpm {--recompile} [--rcfile <file>] [-v] source1.rpm ... sourceN.rpm
              rpm {--resign} [--rcfile <file>] package1 package2 ... packageN
              rpm {--addsign} [--rcfile <file>] package1 package2 ... packageN
              rpm {--checksig -K} [--nopgp] [--nomd5] [--rcfile <file>]
                                  package1 ... packageN
              rpm {--rebuilddb} [--rcfile <file>] [--dbpath <dir>]
              rpm {--querytags}




  Mehr dazu, was die verschiedenen Optionen bewirken, findet man in der
  Manpage des RPM.
  6.  Wozu der RPM wirklich  gut ist

  Der RPM ist ein sehr ntzliches Tool und hat wie gesehen verschiedene
  Optionen. Der beste Weg, sie zu verstehen, ist, sich ein paar
  Beispiele anzuschauen. Einfaches Installieren/Deinstallieren habe ich
  oben behandelt, also folgen hier noch ein paar andere Beispiele:

    Sagen wir, man hat aus Versehen ein paar wichtige Dateien gelscht.
     Um sein gesamtes System zu berprfen und festzustellen, was fehlt,
     gibt man ein:



       rpm -Va





    Falls man eine Datei findet, von der man nicht wei, was fr eine
     es ist, kann man herausfinden, zu welchem Paket sie gehrt, indem
     man eingibt:


       rpm -qf /usr/X11R6/bin/xjewel




  Die Ausgabe wrde wie folgt aussehen:


       xjewel-1.6-1




    Man findet ein neues Koules rpm, hat aber keine Ahnung, was das
     eigentlich ist. Um ein paar Informationen dazu zu bekommen, gibt
     man ein:


       rpm -qpi koules-1.2-2.i386.rpm




  Die Ausgabe wrde wie folgt aussehen:


       Name        : koules                 Distribution: Red Hat Linux Colgate
       Version     : 1.2                          Vendor: Red Hat Software
       Release     : 2                        Build Date: Mon Sep 02 11:59:12 1996
       Install date: (no                      Build Host: porky.redhat.com
       Group       : Games                    Source RPM: koules-1.2-2.src.rpm
       Size        : 614939
       Summary     : SVGAlib action game with multiplayer, network, and sound support
       Description :
       This arcade-style game is novel in conception and excellent in execution.
       No shooting, no blood, no guts, no gore.  The play is simple, but you
       still must develop skill to play.  This version uses SVGAlib to
       run on a graphics console.




    Wenn man sehen will, welche Dateien Koules installieren wrde,
     hilft ein:


       rpm -qpl koules-1.2-2.i386.rpm




  Die Ausgabe ist in diesem Falle:


       /usr/doc/koules
       /usr/doc/koules/ANNOUNCE
       /usr/doc/koules/BUGS
       /usr/doc/koules/COMPILE.OS2
       /usr/doc/koules/COPYING
       /usr/doc/koules/Card
       /usr/doc/koules/ChangeLog
       /usr/doc/koules/INSTALLATION
       /usr/doc/koules/Icon.xpm
       /usr/doc/koules/Icon2.xpm
       /usr/doc/koules/Koules.FAQ
       /usr/doc/koules/Koules.xpm
       /usr/doc/koules/README
       /usr/doc/koules/TODO
       /usr/games/koules
       /usr/games/koules.svga
       /usr/games/koules.tcl
       /usr/man/man6/koules.svga.6




  Das sind nur einige Beispiele. Andere und komplexere kann man schnell
  zusammenstellen, wenn man erst einmal mit dem RPM vertraut ist.


  7.  RPM-Pakete erstellen

  Ein eigenes RPM-Paket zusammenzustellen ist recht einfach,
  insbesondere wenn man die Software, die man in ein Paket
  zusammenpacken mchte, dazu bringen kann, ohne Eingriff eines Nutzers
  automatisch zu kompilieren.

  Der grundlegende Ablauf beim Erstellen eines RPM-Paketes ist wie
  folgt:

    Sicherstellen, da /etc/rpmrc fr das System konfiguriert ist.

    Der Sourcecode, der in das Paket soll, mu auf dem eigenem System
     korrekt kompilieren.

    Einen Patch fr alle Vernderungen erstellen, die notwendig waren,
     damit die Quellen korrekt bersetzt wurden.

    Erstellen einer Spec-Datei fr das Paket.

    Sicherstellen, da alles da ist, wo es hingehrt.

    Paket erstellen mit dem RPM.

  Standardmig erzeugt der RPM sowohl Quell- als auch Binrcode.



  7.1.  Die Datei rpmrc

  Im Moment wird die Konfiguration des RPM ausschlielich ber die Datei
  /etc/rpmrc erledigt. Eine Beispieldatei knnte so aussehen:


       require_vendor: 1
       distribution: Marke Eigenbau!
       require_distribution: 1
       topdir: /usr/src/meins
       vendor: Mickiesoft
       packager:  Mickeysoft Packaging Account <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




  Die Zeile require_vendor veranlat RPM dazu, eine Vendorzeile zu
  verlangen. Diese kann dann sowohl in /etc/rpmrc als auch im Header der
  Spec-Datei selbst festgelegt werden. Um dieses Feature abzuschalten,
  wird es auf 0 gesetzt. Gleiches gilt fr die Zeilen
  require_distribution und require_group.

  Die nchste Zeile ist die distribution Zeile. Diese kann entweder hier
  oder erst spter im Header der Spec-Datei definiert werden. Wenn man
  das Archiv fr eine bestimmte Distribution zusammenstellt, ist es
  sinnvoll, die Zeile entsprechend anzugeben, es ist jedoch nicht
  unbedingt erforderlich. Die vendor Zeile ist hnlich, kann jedoch
  alles mgliche enthalten (z.B. Joe's Software and Rock Music
  Emporium).

  RPM untersttzt jetzt auch das Packen von Archiven fr verschiedene
  Architekturen. Die Datei rpmrc kann ``optflags'' Variablen beinhalten,
  die fr einzelne Architekturen spezifische Flags fr das Kompilieren
  usw. enthalten. Die Verwendung dieser Variablen wird in einem spteren
  Abschnitt behandelt.

  Zustzlich zu den obigen Makros gibt es noch einige weitere. Man kann


       rpm --showrc




  benutzen, um herauszufinden, wie die Tags im Moment gesetzt sind und
  was die verfgbaren Flags sind.


  7.2.  Die Spec-Datei

  Kommen wir jetzt zu den Spec-Dateien. Sie sind erforderlich, um ein
  Paket zu erstellen. Sie enthalten eine Beschreibung der Software,
  Hinweise zum bersetzen der selbigen und eine Dateiliste aller
  Binaries, die installiert werden.


  Man sollte die Spec-Datei nach der Standardkonvention benennen. Diese
  lautet Paketname-Strich-Versionsnummer-Strich-Releasenummer-Punkt-
  spec.

  Hier ein Beispiel fr eine Spec-Datei (vim-3.0-1.spec):


       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




  Die erluternden Texte wie %description oder Summary sollten sin
  nvollerweise in Englisch verfat werden, es sei denn, es handelt sich
  um ein Paket, das nur fr deutschsprachige Anwender gedacht ist.


  7.3.  Der Header

  Der Header hat einige Standardfelder, die angegeben werden mssen. Es
  gibt auch ein paar kleine "Problemzonen", die man kennen sollte. Die
  Felder haben folgenden Inhalt:

    Summary: Kurze Beschreibung des Paketes (eine Zeile)

    Name: Namensstring aus dem Dateinamen, den das RPM-Paket erhalten
     soll

    Version: Versionsstring aus dem Dateinamen, den das RPM-Paket
     erhalten soll

    Release: Releasenummer fr Pakete gleicher Version (d.h. wenn man
     nach dem Zusammenpacken und Verffenlichen seines Paketes
     feststellt, da es doch noch den einen oder anderen kleineren Bug
     enthlt, bekommt die neue Ausgabe nur eine neue, um eins hhere
     Releasenummer)

    Icon: Name der Icondatei, die von anderen Highlevel-
     Installationstools verwendet wird (wie z.B. Red Hat's ``glint'').
     Es mu ein Gif sein, und sich im SOURCES-Verzeichnis befinden.

    Source: Diese Zeile verweist auf die Stelle, von der die originalen
     Quellen stammen. Diese kann man dann verwenden, wenn man einmal das
     ursprnglichen Paket haben will, oder nach neueren Versionen sucht.
     Nachteil: Der Dateiname in dieser Zeile mu 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:


       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




  Diese Dateien wrden im SOURCES Verzeichnis gespeichert werden.  Die
  Verzeichnisstruktur wird in einem spteren Abschnitt diskutiert: "Die
  Struktur der Quellenverzeichnisse".

    Patch: Die Stelle, von der man den Patch wenn ntig herunterladen
     kann. Bedingung: Der Dateiname mu hier dem Namen entsprechen, der
     benutzt wird, wenn man den Patch SELBST anwendet.  Auch hier kann
     man wieder mehrere Patchdateien angeben:


       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




  Diese Dateien werden auch im SOURCES Verzeichnis gespeichert.

    Copyright: Das Copyright des Paketes. Hier sollte etwas von der Art
     GPL, BSD, MIT, public domain, distributable, oder commercial
     stehen.

    BuildRoot: Hier kann ein Verzeichnis festgelegt werden, welches als
     ``root''-Verzeichnis fr die bersetzung und Installation des
     Paketes dient. Man kann diese Mglichkeit einsetzen, um ein Paket
     erst zu testen, bevor man es endgltig auf dem Rechner installiert.

    Group: 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:















  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




    %description Dies ist kein direkter Teil des Headers, wird aber
     trotzdem hier kurz mit erwhnt. Dies ist ein mehrzeiliges Feld, und
     sollte eine kurze Beschreibung des Paketes geben. Man bentigt
     einen Punkt Beschreibung pro Paket und/oder Unterpaket.


  7.4.  Prep

  Das ist der zweite Abschnitt in der Spec-Datei. Hiermit werden die
  Quellen frs bersetzen angepat. Man sollte hier alle Dinge
  veranlassen, die ntig sind, um die Quellen zu patchen und fr ein
  make vorzubereiten.

  Anmerkung: Jeder dieser Abschnitte ist eigentlich nur ein Platz, an
  dem Shellskripte ausgefhrt werden. Man knnte einfach ein Shellskript
  schreiben, das nach dem %prep Tag eingetragen wird und die Quellen
  entpackt und patcht. Wir haben jedoch Makros geschrieben, die das ein
  wenig vereinfachen sollen.

  Das erste dieser Makros ist das %setup Makro. Im einfachsten Fall
  (keine Parameter auf der Kommandozeile) entpackt es nur die Quellen
  und macht ein cd ins Quellverzeichnis.  Es versteht die folgenden
  Optionen:

    -n name setzt den Namen des bersetzungsverzeichnisses auf den
     angegebenen Namen name. Der Defaultwert ist $NAME-$VERSION. Andere
     Mglichkeiten sind $NAME, ${NAME}${VERSION} oder was immer das
     Haupttararchiv enthlt. (Man beachte, da die hier genannten ``$''
     Variablen keine echten Variablen, die im Specfile zur Verfgung
     stehen, sind, sondern nur als Platzhalter anstelle von
     Beispielnamen stehen. Man mu die echten Namen und Versionen der
     Pakete einsetzen, keine Variablen.)

    -c erstellt und wechselt in das angegebene Verzeichnis vor dem
     Entpacken.

    -b # entpackt Source# vor dem Wechseln in das Verzeichnis (nicht in
     Verbindung mit -c verwenden). Diese Option ist nur sinnvoll fr
     mehrere Quelldateien.

    -a # entpackt Source# nach dem Wechseln in das Verzeichnis.

    -T Diese Option verhindert die Default-Aktion des Entpackens der
     Quellen und erfordert ein -b 0 oder -a 0 um die Hauptquelldatei zu
     entpacken. Das wird bentigt, wenn es noch andere Quellen gibt.

    -D Das Verzeichnis nicht vor dem Entpacken lschen.  Das ist nur
     sinnvoll, wenn man mehr als ein Setup-Makro hat. Die Option sollte
     nur in Setup-Makros nach dem ersten Makro benutzt werden, aber nie
     im ersten.

  Das nchste verfgbare Makro ist das %patch Makro. Dieses Makro
  erleichtert das Anwenden von Patches auf die Quellen. Es kennt die
  folgenden Optionen

    # verwendet Patch# als Patchfile.

    -p # gibt die Anzahl der Verzeichnisse an, die fr das patch(1)
     Kommando vom Pfad (siehe auch Man-Page von patch)entfernt werden.

    -pN Fhrt ein patch -pN < $RPM_SOURCE_DIR/patchname/ aus, wobei
     patchname der Name des Patches aus der Patch-Zeile im Header ist.
     Diese Option ist ntzlich fr die Anwendung weiterer Patches, wenn
     fr diese eine andere Anzahl von Verzeichnissen vom Pfad entfernt
     werden mu als fr das erste Makro.

    %patch# ist an Stelle des richtigen Kommandos %patch # -pN auch
     mglich

  Das sollten alle Makros sein, die man bentigt. Wenn man diese richtig
  verstanden hat, kann man auch andere Arten von Setup's via sh-Skripten
  erstellen. Alles was bis zum %build Makro, nher erlutert im nchsten
  Abschnitt, eingefgt wird, wird von der sh abgearbeitet. Siehe das
  Beispiel oben fr Aktionen, die hier ausgefhrt werden knnen.


  7.5.  Build

  Fr diesen Abschnitt gibt es keine eigenen Makros. Hier werden alle
  Kommandos eingetragen, die notwendig sind, um ein Programm zu
  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 shzur Ausfhrung
  bergeben werden, d.h. alle gltigen sh-Kommandos knnen hier benutzt
  werden, inklusive Kommentare. Das aktuelle Verzeichnis wird nach jedem
  dieser Abschnitte wieder auf das Toplevel-Verzeichnis der Quellen
  gesetzt, man sollte das immer beachten. Man kann, wenn notwendig, in
  ein Unterverzeichnis wechseln.


  7.6.  Install

  Auch fr 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 make install
  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.


  7.7.  Optionale Pre- und Postinstall/deinstall Skripten

  Hier knnen Skripten angegeben werden, die vor und nach der
  Installation und der Deinstallation von fertig bersetzten Paketen
  abgearbeitet werden.  Einer der Hauptgrnde dafr ist das Ausfhren
  von speziellen Programmen, wie z.B. ldconfig nach dem Installieren
  oder Entfernen von Paketen mit Shared Libraries. Die Makros fr die
  jeweiligen Skripte sind:

    %pre ist das Makro zum Ausfhren von Pre-Install Skripten.

    %post ist das Makro zum Ausfhren von Post-Install Skripten.

    %preun ist das Makro zum Ausfhren von Pre-Deinstall Skripten.

    %postun ist das Makro zum Ausfhren von Post-Deinstall Skripten.

  Der Inhalt dieser Abschnitte ist ein beliebiges sh-Skript, jedoch ohne
  die #!/bin/sh Zeile.


  7.8.  Files

  In diesem Abschnitt mssen die Dateien des fertig bersetzten Paketes
  angegeben werden. RPM hat keine Mglichkeit, herauszufinden, welche
  Dateien als Ergebnis eines make install im System installiert werden.
  Hierfr gibt es KEINE Mglichkeit. Es gab Vorschlge, dieses mit einem
  find vor und nach dem Installieren zu bewerkstelligen. In einem
  Multiusersystem, bei dem zur gleichen Zeit von anderen Prozessen
  Dateien geschaffen werden knnen, die mit dem Paket nichts zu tun
  haben, ist dies jedoch nicht sinnvoll.

  Hier gibt es ebenfalls einige Makros fr spezielle Zwecke. Folgende
  Makros stehen zur Verfgung:

    %doc bezeichnet Dokumentation aus dem Quellpaket, die zusammen mit
     den bersetzten Binrpaketen installiert werden soll. Sie wird in
     /usr/doc/$NAME-$VERSION-$RELEASE installiert.  Man kann mehrere
     Dokumente auf einer Kommandozeile auflisten oder je eins pro
     separatem Makro.

    %config bezeichnet Konfigurationsdateien aus dem Paket.  Dies
     beinhaltet z.B. Dateien wie sendmail.cf, passwd usw. Wenn man
     spter das Paket deinstalliert, werden unvernderte
     Kofigurationsdateien mit dem Paket gelscht und vernderte mit
     einem angehngten .rpmsave gesichert.  Auch hier knnen einem Makro
     mehrere Dateien bergeben werden.

    %dir bezeichnet ein Verzeichnis in einer Dateiliste, welches
     komplett mit zum Paket gehrt. Normalerweise wird ein Verzeichnis,
     das OHNE ein %dir Makro aufgefhrt wird, zusammen mit seinem
     KOMPLETTEN Inhalt in die Dateiliste aufgenommen und spter mit dem
     Paket zusammen installiert.

    %files -f <filename> ermglicht das Auflisten der zugehrigen
     Dateien in einer beliebigen anderen Datei im
     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 sie dann nicht extra
     hier einfgen.

  Das grte Problem der Dateilisten ist das Auflisten von
  Verzeichnissen.  Wenn man aus Versehen /usr/bin mit auflistet, werden
  alle Dateien in /usr/bin des Systems als zum Paket gehrig betrachtet.
  .

  7.9.  bersetzen


  7.9.1.  Die Struktur der Quellenverzeichnisse

  Zunchst braucht man natrlich einen passenden Verzeichnisbaum fr die
  Quelldateien. Man kann diesen in der Datei /etc/rpmrc festlegen,
  blicherweise wird hier einfach /usr/src verwendet.

  Eventuell mssen die folgenden Verzeichnisse angelegt werden, um einen
  Verzeichnisbaum fr das bersetzen zu erstellen:

    BUILD ist das Verzeichnis, in dem die bersetzung durch den RPM
     stattfindet. Man mu seine Testbersetzungen nicht in diesem
     speziellen Verzeichnis durchfhren, aber hier ist es, wo der RPM
     seine bersetzungen durchfhrt.

    SOURCES hier sollten alle tar-Archive der originalen Quellen und
     die Patches stehen. Hier sucht der RPM per Default nach den
     Quelldateien.

    SPECS hier gehren die Spec-Dateien hin.

    RPMS das Verzeichnis fr die fertig bersetzten rpm's.

    SRPMS das Verzeichnis fr die Quell-rpm's.


  7.9.2.  Testbersetzung

  Zunchst sollte man dafr sorgen, da die Quellen korrekt ohne den RPM
  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 bersetzen benutzt.
  Man wechselt ins Quellverzeichnis und folgt den Anweisungen zum
  bersetzen des Paketes. Wenn man, um die Quellen zu bersetzen,
  nderungen an ihnen vornehmen mute, braucht man ein Patch. Um einen
  solchen zu erstellen, entfernt man alle Dateien, die von einem
  configure Skript o.. angelegt wurden, aus dem Verzeichnis, das die
  jetzt vollstndig bersetzbaren Quellen enthlt. Danach wechselt man
  in das bergeordnete Verzeichnis des obersten Quellverzeichnisses.
  Danach wird der Patch erstellt mit


       diff -uNr verzname.orig verzname > ../SOURCES/dirname-linux.patch




  o.., 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 ber den Grund fr diesen Patch aussagt, z.B. ``config''
  oder ``bugs''. Man sollte auerdem noch einen Blick in die fertige
  Patchdatei werfen, um sicherzustellen, da nicht aus Versehen Binaries
  o.. mit eingetragen wurden.


  7.9.3.  Erstellen der Dateiliste

  Nachdem man funktionierende Quellen hat, werden diese bersetzt und
  installiert, so wie es beim Endbenutzer geschehen wrde. 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 ergnzt dann nach und nach die
  anderen Teile im weiteren Verlauf.


  7.9.4.  Erstellen des Paketes mit dem RPM

  Wenn die Spec-Datei fertig ist, kann man versuchen, ein RPM-Paket zu
  erzeugen. Dies geschieht meistens mit einem



       rpm -ba foobar-1.0.spec




  Es gibt weitere Optionen, die mit dem -b Switch zusammen ntzlich
  sind:

    p Ausfhren des prep Abschnittes der Spec-Datei.

    l ist ein Listencheck, der einige Tests mit %files macht.

    c Ausfhren 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
     blicherweise erst zum 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.

    i Ausfhren von prep, kompilieren, installieren.

    b Ausfhren von prep, kompilieren, installieren, erstellen nur des
     Binrpaketes.

    a alles erstellen (Quell- und Binrpakete).

     Es gibt noch einige Optionen zum Modifizieren des Ablaufs des -b-
     Switch:

    --short-circuit beginnt direkt mit dem angegebenen Abschnitt (nur
     zusammen mit c und i).

    --clean entfernt nach Beendigung die bersetzungsverzeichnisse.

    --keep-temps behlt alle temporren Dateien und Skripte, die in
     /tmp angelegt wurden. Mit der Option -v kann man sehen, was in /tmp
     erzeugt wurde.

    --test fhrt keine wirklichen Aktionen aus, aber bewahrt temp-
     Dateien.


  7.10.  Austesten

  Wenn man ein fertiges Paket fr die Quellen und die Binaries hat,
  sollte man es testen. Das Beste und Einfachste ist es, das Paket auf
  einem vllig anderen Rechner zu testen als dem, auf dem man es
  erstellt hat.  Schlielich hat man das Paket bereits mehrfach auf
  diesem Rechner mit make install o.. installiert, so das es nun
  bereits recht gut installiert sein sollte.

  Man kann das Paket mit rpm -u packagename zwar wieder deinstallieren,
  wenn man aber in der Liste der Dateien eine oder mehrere vergessenen
  hat, die aber durch das make install installiert wurden, werden diese
  nicht wieder deinstalliert. Wenn man danach das Paket wieder
  installiert, ist es wieder vollstndig auf dem Rechner, auch wenn das
  rpm selbst unvollstndig ist.  Darber hinaus sollte man beachten, da
  man selbst zwar eine Testinstallation mit rpm -ba package macht, die
  meisten Leute jedoch nur ein rpm -i package machen werden. Man mu
  daher darauf achten, da in den build oder install Abschnitten nichts
  getan wird, was auch fr eine reine Installation der Binaries
  notwendig ist.




  7.11.  Wenn das neue rpm fertig ist

  Wenn man ein neues rpm von irgend etwas fertiggestellt hat, kann man
  es - unter der Voraussetzung, da es noch nicht als rpm existiert -
  anderen zur Verfgung stellen. Hierbei mu das, was man
  zusammengepackt hat, natrlich ein entsprechendes Copyright haben. Man
  kann es dann auf den FTP-Server ftp.redhat.com stellen.


  7.12.  Was weiter?

  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 mglich in guter Qualitt zur Verfgung
  stellen.  Bitte die rpm's grndlich austesten und dann zum Nutzen
  aller ins Netz stellen. Unbedingt sollte man jedoch vorher
  sicherstellen, da das Copyright dieses auch zult. Kommerzielle
  Software und Shareware sollte nicht ffentlich zur Verfgung gestellt
  werden, es sei denn, das Copyright der entsprechenden Software lt
  das ausdrcklich zu. Das gilt z.B. fr Programme wie Netscape, ssh,
  pgp, usw.


  8.  RPM's fr verschiedene Architekturen

  RPM unterstzt jetzt das Erstellen von Paketen fr Intel i386, Digital
  Alpha mit Linux und Sparc. Berichte besagen, da es auch auf SGI's und
  HP's funktionieren soll. Eine Reihe von Eigenschaften vereinfachen das
  Erstellen von Paketen auf allen Plattformen. Die erste ist die
  ``optflags'' Direktive in /etc/rpmrc. Sie kann dazu benutzt werden,
  Flags, die beim bersetzen von Paketen verwendet werden, auf
  architekturspezifische Werte zu setzen. Ein anderes Beispiel sind die
  ``arch'' Makros in der Spec-Datei. Sie knnen dazu benutzt werden,
  unterschiedliche Aktionen auszulsen, je nachdem, auf welcher
  Architektur bersetzt wird. Eine andere Mglichkeit ist die
  ``Exclude'' Direktive im Header.


  8.1.  Beispiel fr eine Spec-Datei

  Der folgende Ausschnitt ist Teil des ``fileutils''-Paketes. Es ist fr
  das bersetzen auf der Intel- und Alphaplattform konfiguriert.


       Summary: GNU File Utilities
       Name: fileutils
       Version: 3.16
       Release: 1
       Copyright: GPL
       Group: Utilities/File
       Source0: prep.ai.mit.edu:/pub/gnu/fileutils-3.16.tar.gz
       Source1: DIR_COLORS
       Patch: fileutils-3.16-mktime.patch

       %description
       These are the GNU file management utilities.  It includes programs
       to copy, move, list, etc, files.

       The ls program in this package now incorporates color ls!

       %prep
       %setup

       %ifarch alpha
       %patch -p1
       autoconf
       %endif
       %build
       configure --prefix=/usr --exec-prefix=/
       make CFLAGS="$RPM_OPT_FLAGS" LDFLAGS=-s

       %install
       rm -f /usr/info/fileutils*
       make install
       gzip -9nf /usr/info/fileutils*

       .
       .
       .





  8.2.  Optflags


  In diesem Beispiel wird gezeigt, wie man die ``optflags''-Direktive
  aus /etc/rpmrc einsetzt. In Abhngigkeit von der jeweiligen
  Architektur wird die Variable RPM_OPT_FLAGS auf den entsprechenden
  Wert gesetzt.  Das Makefile mu angepat werden, damit hier dann diese
  Variable anstelle der blichen Direktiven wie -m486 oder -O2 verwendet
  wird. Man kann sich ein Gefhl dafr verschaffen, was gemacht werden
  mu, indem man sich erwhntes Quellpaket installiert und das Makefile
  ansieht. Dazu kann man sich dann im Vergleich den Patch anschauen, um
  zu sehen, welche nderungen notwendig sind.


  8.3.  Makros

  Sehr wichtig ist das Makro %ifarch. Meistens mu man den einen oder
  anderen Patch machen, der nur fr eine bestimmte Architektur angewandt
  werden soll. In diesem Fall sorgt der RPM mit Hilfe dieses Makros fr
  die korrekte Verwendung der Patches. Im obigen Beispiel hat das
  fileutils-Paket einen Patch fr 64-bit Architekturen. Dieser Patch
  soll natrlich im Moment nur fr Alpha-Rechner angewandt werden.
  Deshalb wird ein %ifarch Makro um den 64-bit Patch herumgelegt:


       %ifarch axp
       %patch1 -p1
       %endif




  Das stellt sicher, da der Patch ausschlielich fr Alphas verwendet
  wird.


  8.4.  Ausschlieen von  Architekturen in Paketen

  Damit man die Quell-rpm's fr alle Plattformen weiterhin in einem
  Verzeichnis aufbewahren kann, haben wir die Mglichkeit geschaffen,
  Pakete von der bersetzung auf bestimmten Architekturen
  auszuschlieen. Das ermglicht weiterhin Dinge wie eine bersetzung
  ganzer Gruppen von Paketen mit einem Mal, z.B. mit einem


       rpm --rebuild /usr/src/SRPMS/*.rpm




  ,wobei man trotzdem dann nur die passenden bersetzten Pakete erhlt.
  Falls ein Programm noch nicht auf eine bestimmte Plattform portiert
  wurde, reicht ein Einfgen einer Zeile wie:


       ExcludeArch: axp




  in den Header der Spec-Datei des Quellpaketes. Danach erstellt man das
  rpm auf der Architektur, auf der es luft, und erhlt so ein Paket,
  das z.B. auf Intel bersetzt wird, aber auf Alphas einfach bergangen
  wird.


  8.5.  Zusammenfassung

  Oft ist es einfacher, den RPM zum Erstellen von Paketen fr mehrere
  Architekturen einzusetzen als das Paket selber dazu zu bringen. Wie
  blich ist der beste Weg, wenn man mit seinem rpm nicht mehr weiter
  wei, einen Blick auf hnliche andere rpm's zu werfen.



