Vorwort
Dies ist eine von pinoc übersetzte und von maik3531 angepasste und erweiterte Anleitung des englischsprachigen „RPM HowTo“. Das englischsprachige Original ist unter http://mypclinuxos.com/rpm-how-to zu finden. Ich habe mir auch das Recht genommen, an einigen Stellen den Text zu verändern oder auch Links ausgetauscht. So führt z.B. der Link von PCLinuxOS nicht zum Original sondern zur deutschsprachigen Community.
Diese Anleitung ist für PCLinuxOS RPMs spezifiziert, ist jedoch sicher auch für anderen Distributionen zu einen großen Teil verwendbar.
Warum diese Anleitung? „Weil Sie im vergleich zu vielen anderen Anleitungen oder gar Büchern zum Thema RPM-Erstellung alles wichtige beinhaltet, dabei jedoch auf jeden Punkt verhältnismäßig kurz aber Präzise eingeht.“ Sollten Sie diese Meinung teilen oder auch nicht lassen Sie mich es wissen, denn nur so kann man bei letzteren etwas ändern.
Lizenz
Sowohl als Dokument (in Form von *.pdf/ *.odf/ usw.) als auch auf der Webseite gilt der verfasste Text, jedoch ohne Bezug auf die hier erwähnten Tools und/oder Links, als GPL lizensiert. Das bedeutet man kann Texte kopieren, die Dokumente vervielfachen und/oder auch weitergeben. Natürlich sind auch Änderungen am Text erlaubt und erwünscht nur wäre es schön wenn Sie mich über evtl. Änderungen informieren würden (falls diese von Nutzen sind, so dass die anderen User auch was davon haben). Keine Gewähr für Vollständigkeit/Richtigkeit dieser Anleitung, deren Benutzung erfolgt auf eigene Verantwortung!
Der RedHat Package Manager (RPM) ist ein leistungsfähiges Paket Management System für die Konsole. Es erlaubt die Installation, Deinstallation, Abfrage, Verifizierung, und das Updaten von Software Programmen. Jedes Software Programm besteht aus einem Dokumentenarchiv. Neben einer Beschreibung und der Programmversion, beinhaltet das Archiv API Bibliotheken welche von Software Entwicklern zur Ausführung der Programme, geschrieben in z.B. C, C++ oder Python, genutzt werden.
RPM ist freie Software, veröffentlicht unter der GNU GPL.
(inoffizielle deutsche Übersetzung der GPL)
Diese Anleitung soll Usern helfen die lernen möchten wie man RPMs baut, entweder für sich selbst oder für die Community. Ich habe diese Anleitung geschrieben um zu zeigen wie man qualitativ hochwertige RPMs erstellt. Wenn Sie sich entschieden haben RPMs auf die hier vorgegebene Weise zu erstellen dann tun Sie das weil Sie diese auch anderen Usern zur Verfügung stellen möchten.
Diese Anleitung beschreibt das Erstellen von RPMs für die Plattform i586 der Linux Distribution PCLinuxOS. Diese Anleitung richtet sich an diejenigen, die mit der Konsole und Befehlszeilen (rpm -ivh , rpm -Uvh -force etc.) vertraut sind.
Die RPM Erstellung ist sehr variable und reicht von einfachen, kleinen Anwendungen bis hin zu komplexen Ansammlungen von Bibliotheken mit wechselseitigen Abhängigkeiten. Das Erstellen erfordert nicht notwendigerweise das Verständnis einer Programmiersprache. Ein richtig guter Paketbäcker jedoch versteht die Programmiersprache der Anwendung und ist daher in der Lage nicht nur den Quellcode zu verstehen sondern auch gegeben-falls dort /Änderungen vorzunehmen um die Installation zu gewährleisten.
Keine Panik, Sie können auch als Nicht-Programmierer RPMs erstellen und das RPM System wird Ihnen dabei helfen.
#PCLinuxOS official repos auffinden. Jede Zeile die nicht mit einem # beginnt ist eine aktive Quelle (Repository). An das Ende dieser Zeile das Wort „testing“ hinzufügen, es sollte dann z.B. so aussehen:rpm http://spout.ussg.indiana.edu/linux/pclinuxos/pclinuxos/apt/ pclinuxos/2007 main extra nonfree kde testing
Anmerkung: Falls Probleme mit der testing Quelle auftreten diese bitte an die PCLinuxOS mailing list melden. Dies betrifft jedoch nur Probleme mit PCLinuxOS RPMs.
Im nächsten Schritt öffnen wir Synaptic und führen ein Neu Laden → Aktualisierungen vormerken (Reload → Mark all Upgrades) aus.
Bevor dies mit Ausführen (Apply) bestätigt wird suchen und markieren wir noch die folgenden Pakete:
oder für KDE 4
oder für den Thunar Dateimanager
Abschließend werden diese über Vormerken → Ausführen installiert. Fertig!
Um dass System nicht zu gefährden erstellen wir eine eigenständige RPM Bau-Umgebung. Die Standardeinstellung dieser Umgebung ist /usr/src/rpm und man braucht Root-Rechte um dort schreiben zu können. Als Root zu arbeiten ist jedoch gefährlich da man hier durch Unachtsamkeit beim RPM Bauen, und nicht nur da, das System beschädigen oder sogar komplett unbrauchbar machen kann.
Wir erstellen daher eine eigene RPM Bau-Umgebung mittels folgender Verzeichnisstruktur in unserem Persönlichen Verzeichnis:
Sollte mkrepo nicht Ordnungsgemäß ausgeführt werden beim installieren von pkgutils, starten Sie bitte eine Konsole/Terminal und geben Sie den Befehl mkrepo ein. Folgen Sie den Anweisungen und entscheiden Sie sich jeweils für einen Namen, wenn Sie gefragt werden was Sie nehmen wollen. z.B. user-or-pclos. Nehmen Sie entweder user oder pclos.
(<username> durch Ihren Benutzernamen ersetzen und auf Groß-/Kleinschreibung achten)
Durch die Nutzung von mkrepo wird alles so erstellt wie nachfolgend beschrieben ist.
/home/<username>/RPM/RPMS/noarch (hier werden die Mehrfacharchitekturen rpms erzeugt) /home/<username>/RPM/RPMS/i586 (hier werden die i586 rpms erzeugt) /home/<username>/RPM/RPMS/i686 (hier werden die i686 rpms erzeugt) /home/<username>/RPM/RPMS/i486 (hier werden die i486 rpms erzeugt) /home/<username>/RPM/RPMS/i386 (hier werden die i386 rpms erzeugt) /home/<username>/RPM/RPMS/athlon (hier werden die athlon rpms erzeugt) /home/<username>/RPM/BUILD (hier werden die Quell Dateien (source files) während des Bauens installiert) /home/<username>/RPM/SRPMS (hier werden die source rpms (srpms) erzeugt) /home/<username>/RPM/SOURCES (hier kommt der Quelltext zur Erstellung des RPMs hin) /home/<username>/RPM/SPECS (hier kommt der spec file zum Bauen des RPM hin) /home/<username>/RPM/tmp (hier wird das RPM erstellt und eventuelle Fehlermeldungen (error logs) gespeichert)
Die obige Verzeichnisstruktur kann auf einfache Weise erstellt werden indem die folgenden Befehle kopiert und in einer normalen Konsole in Ihren Persöhnlichen Verzeichnis (nicht als Root!) eingefügt werden:
cd ~ mkdir -p RPM/RPMS/i386 mkdir -p RPM/RPMS/i486 mkdir -p RPM/RPMS/i586 mkdir -p RPM/RPMS/i686 mkdir -p RPM/RPMS/x86_64 mkdir -p RPM/RPMS/noarch mkdir -p RPM/RPMS/athlon mkdir -p RPM/SRPMS mkdir -p RPM/SOURCES mkdir -p RPM/SPECS mkdir -p RPM/BUILDROOT mkdir -p RPM/BUILD mkdir -p RPM/tmp
Bzw.
mkdir -p ~/RPM/{BUILD,RPMS/i386,RPMS/i486,RPMS/i586,RPMS/i686,RPMS/x86_64,RPMS/athlon,RPMS/noarch,SOURCES,SPECS,SRPMS,tmp}
Als nächstes müssen wir dem System mitteilen das wir unsere eigenes RPM Bau-Umgebung nutzen wollen. Hierzu erzeugen wir zwei einfache Textdokumente in unserem Persöhnlichen Verzeichnis (/home/<username>). Bitte beachten das der Name der beiden Dokumente mit einem Punkt beginnt!
Das erste Dokument hat den Namen „.rpmrc“ und hat folgenden Inhalt:
buildarchtranslate: i386: i586 buildarchtranslate: i486: i586 buildarchtranslate: i586: i586 buildarchtranslate: i686: i586
PCLinuxOS verwendet ausschließlich die i586 Architektur und adaptiert auf diese Weise RPMs die von Entwicklern auf andere Architekturen gesetzt wurden.
Das zweite Dokument hat den Namen „.rpmmacros“ und folgenden Inhalt (bitte <username> mit Eurem Username ersetzen und „#pclos#“ personalisieren Sie mit z.B. Ihrem PCLinuxOS Username)
%_topdir /home/<username>/RPM %_tmppath /home/<username>/RPM/tmp %distribution PCLinuxOS %vendor PCLinuxOS Community %distsuffix #pclos#
Achtung: Diesen bisherigen Abschnitt (sowohl das installieren der wichtigsten RPMs zur Erstellung von RPMs, als auch die Erstellung solch einer Ordnerstruktur, der Erstellung einer .rpmrc und einer .rpmmacros sowie das Ändern Eurer sources.list) kann auch ein Script (RPMBau-de) für Sie übernehmen welches Sie unter www.maik3531.de downloaden könnt.
Das System ist nun fast einsatzbereit und wir betrachten nun die „spec-files“!
Zum Bauen eines RPMs benötigt man den Quelltext des Programms und die sogenannten „spec“ Datei, welche die RPM Bauanleitung beinhaltet.
Während man den Quelltext direkt von der Entwicklerseite herunterladen kann muss die Spec-Datei meist selbst geschrieben werden. Hierfür gibt es mehrere Möglichkeiten.
Die Spec-Datei beinhaltet den „Bauplan“ des RPMs und ist daher der wichtigste Bestandteil beim RPM-Bau. Sie kann aus einem älteren RPM Paket extrahiert oder von Grund auf neu geschrieben werden.
Sollte eine ältere Version des zu bauenden RPM Pakets bereits existieren (wer googled der findet), dann kann man das entsprechende Source-RPM herunterladen. Dieses ist auch unter dem Namen SRPM mit der Endung „src.rpm“ bekannt. Hierbei gilt folgende Präferenz:
Die obige Liste gibt den Kompatibilitätsgrad mit PCLinuxOS an. Von PCLinuxOS selbst einmal abgesehen bieten Mandriva RPMs die höchste Kompatibilität da PCLinuxOS von Mandriva abgeleitet ist, Mandriva von RedHat (Fedora), und SuSE von RedHat.
Nun gehen wir in das Verzeichnis dass das heruntergeladene SRPM enthält, öffnen die Konsole, und geben den folgenden Befehl - als User (nicht als Root!) ein:
rpm -ivh NameDesSourceRPM.src.rpm
Dieser Befehl installiert automatisch die Spec-Datei, den Quelltext und eventuelle Patches in die jeweiligen Verzeichnisse: Die Spec-Datei in ~/RPM/SPECS/, den Quelltext und Patches in ~/RPM/SOURCES/.
Nun muss man nur noch die Spec-Datei dahingehend ändern das sie auf den neuen Quelltext hinweist und PCLinuxOS konform wird, denn Spec-Dateien sind distributionsspezifisch. Desweiteren muss die Gültigkeit und Relevanz der Patches für unsere PCLinuxOS Distribution überprüft werden.
Steht gar keine, oder nur eine teilweise geeignete Spec-Datei zur Verfügung dann müssen wir sie entweder ganz neu schreiben oder entsprechend komplementieren. Hierfür gibt es mehrere Möglichkeiten und wir beschreiben hier nur die PCLinuxOS konforme Spec-Datei. Um die Integrität von PCLinuxOS zu gewährleisten können nur RPMs mit PCLinuxOS konformen Spec-Dateien aufgenommen werden. RPMs mit nicht PCLinuxOS konformen Spec-Dateien mögen zwar funktionieren aber müssen zur Aufnahme in das PCLinuxOS Repository PCLinuxOS konform neu kompiliert werden.
Nachdem das ganz klar ist werfen wir nun einen Blick in das Innenleben einer Spec-Datei. Dessen Namenskonvention ist NameDesQuelltextTarball.spec (bitte keine Versionsnummern). Übrigens, Kwrite erkennt einen Spec-Datei automatisch und bringt sie in das richtige Format welches nützlich ist um Tippfehler zu vermeiden.
Wir beginnen mit einem Beispiel einer einfachen aber vollständigen Spec-Datei des Programms cwallpaper für tinyme2007. Als kleine Übung kann diese Spec-Datei auch aus dem SRPM des TinyMe main SRPMs Verzeichnisses extrahiert werden.
%define name cwallpaper
%define version 0.3
%define release %mkrel 1
Summary: Cwallpaper is a GUI front end for wallpaper utilies such as xsetroot.
Name: %name
Version: %version
Release: %release
License: GPL
Group: Applications/Multimedia
Source: %{name}-%{version}.tar.gz
BuildRoot: %_tmppath/%name-%version-buildroot
Requires: cwallpaper-update
URL: http://www.sourceforge.net/
%description
Cwallpaper is a GUI front end for wallpaper utilies such as xsetroot.
%prep
%setup -q
%build
%{configure} --prefix=%{_prefix}
%{__make} %{?_smp_mflags} %{?mflags}
%install
%{__make} %{?mflags_install} DESTDIR=$RPM_BUILD_ROOT install
%clean
test "x$RPM_BUILD_ROOT" != "x/" && rm -rf $RPM_BUILD_ROOT
%post
/sbin/ldconfig
%postun
/sbin/ldconfig
%files
%defattr(-, root, root)
%{_bindir}/cwallpaper
%{_datadir}/cwallpaper/*
%changelog''
* Wed Aug 15 2007 Gettinther <gettinther@gmail.com> 0.3-1pclos_tinyme2007
- rebuild for pclos2007
- Dependency on cwallpaper-update script added by KDulcimer
define makros (name, version, release können auch direkt in der präambel angegeben werden, also Release: 1, Name: abc, Version: 0.1)
Die Spec-Datei besteht aus 3 Abschnitten:
(es gibt noch den changelog aber das ist kein eigenständiger Abschnitt)
Die zusammenfassende Beschreibung in unserem Beispiel (cwallpaper.spec) sieht folgendermaßen aus:
%define name cwallpaper
%define version 0.3
%define release %mkrel 1
Summary: Cwallpaper is a GUI front end for wallpaper utilies such as xsetroot.
Name: %name
Version: %version
Release: %release
License: GPL
Group: Applications/Multimedia
Source: %{name}-%{version}.tar.gz
BuildRoot: %_tmppath/%name-%version-buildroot
Requires: cwallpaper-update
URL: http://www.sourceforge.net/|http://www.sourceforge.net/
Diese Zusammenfassung enthält die gesamte Information des zu bildenden RPM Pakets. Keine Bange vor den Macros (Textstellen die mit einem „%“ beginnen), diese besprechen wir später.
configure.ac im Quelltext. Eine weitere Möglichkeit besteht darin, den RPM Bau zu testen und aus den Fehlermeldungen der fehlenden Bibliotheken die notwendigen Abhängigkeiten abzuleiten. Als letzte Option kann die beim Abschluss des RPM Baus erzeugte Meldung der Abhängigkeiten für Synaptic verwendet werden, jedoch ist diese nicht immer zuverlässig und sollte nichtausschließlich verwendet werden.
Es folgt ein Beispiel des configure.ac Dokuments von cwallpaper:
AC_PROG_CC
dnl you should add CFLAGS="" here, because it is set to -g by PROG_CC
AM_GTK_PATH_2_0(2.2.0,,AC_MSG_ERROR(cwallpaper 0.3 needs ''''GTK+ 2.0''''))
AC_OUTPUT(
Makefile \
src/Makefile \
)
Dieses Beispiel zeigt, dass cwallpaper GTK+ 2.0 benötigt und unser System muss diese Abhängigkeit während der RPM Erstellung erkennen. In Synaptic suchen wir nun nach dem Paket und dessen mitgelieferten Paketen (in unserem Fall libgtk+2.0) und tragen diese unter Beachtung von Groß- und Kleinschreibung in die Spec-Datei ein. Die meisten Anwendungen erfordern außerdem noch die Entwicklungspakete (development files) der benötigten Pakete. Als Faustregel gilt: die Pakete die in der configure.ac gefunden wurden, sollten in die Liste der „Requires:“ jeweils mit einem Leerzeichen separiert eingetragen werden. Das Entsprechende gilt für die Entwicklungspakete (-devel Dateien) in die „BuildRequires:“ Liste, in unserem Beispiel also:
BuildRequires: libgtk+2.0-devel Requires: libgtk+2.0
Alle bisher erwähnten Einträge sind zwingend erforderlich. Sollte hier irgendetwas fehlen dann kann Ihr RPM nicht aufgenommen werden und es muss unnötigerweise vom offiziellen PCLinuxOS Paketbäckern korrigiert und neu gebaut werden! Wenn Sie möchten können Sie den Namen des Paketbäckers hinzufügen:
Packager: Username
Dieser Name erscheint in Synaptic und anderen Paketmanagern. Es gibt noch weitere Einträge aber im Moment belassen wir es hierbei. Bei Requires und BuildRequires kann es vorkommen das man Abhängigkeiten mit Versionsnummer angeben muss. Zusätzlich kann man aber auch angeben das eine Paket-Abhängigkeit Größer/Kleiner oder gleich wie angegeben sein muss.
Bsp.
BuildRequires: qt4-devel >= 4.3.2
(>= 4.3.2 bedeutet das dass benötigte Paket > (größer als) oder = (gleich) mit angegebener Versionsnummer sein muss)
Versionsnummer im Beispiel muss also mindestens 4.3.2 sein.
Achtung: mit Vorsicht genießen!
Dieser Teil ist „unter anderem“ nicht mit im englischen Original enthalten, ob und wenn ja welche Bestandteile da für offizielle Quellen genutzt werden dürfen entzieht sich noch meiner Kenntnis.
Manchmal ist es notwendig einen Konflikt mit anderen Paketen zu vermeiden oder selbes Paket ist bereits unter einem anderen Namen (z.B. eine ältere Version) jedoch mit selben Inhalt vorhanden. Auch Hier gibt es Möglichkeiten dies in der Spec zu definieren.
Suggests: „Paketname"
Suggests: Bedeutet: schlägt „Packetname“ zur Installation vor. (Sollte ein Paket nicht unbedingt erforderlich sein, aber wenn es da ist sollte es zur Installation vorgeschlagen werden).
Conflicts: „Paketname"
Conflicts: Bedeutet: kann nicht gleichzeitig wie „Paketname“ installiert werden. (Wenn wie schon beschrieben sich zwei Pakete nicht mit einander vertragen).
Obsoletes: „Paketname"
Obsoletes: Bedeutet: Paket ist neuer als „Packetname“ und ersetzt dieses. (Wie oben bereits erwähnt, wenn es beispielsweise das selbe Paket unter einen anderen Namen schon gibt).
Wenn der Obsoletes-Tags verwendest wird, musst immer zusätzlich noch das obsolete Pakete bereitstellen. Bsp:
Obsoletes: abc Provides: abc
Das gilt auch für jedes Teilpaket.
PreReq: Bedeutet: andere Abhängigkeit muss bereits installiert sein bevor dieses Paket installiert werden kann. Im Vergleich zu „Requires:“ reicht es nicht das diese Abhängigkeit gleich mit installiert wird sondern muss bereits installiert sein.
Achtung: mit Vorsicht genießen!
Was aber tun wenn Abhängigkeiten (mit unter auch einzelne Dateien) vom RPM automatisch als Abhängigkeit erkannt werden, diese aber bereits im System vorhanden sind oder bereits im System mit anderen Namen vorhanden sind. Mitunter auch wenn eine Abhängigkeit nicht notwendig ist (jedoch für andere Systeme eine pflicht Voraussetzung darstellt).
AutoReq : No AutoProv : No
Mitunter auch als „Autoreqprov: on/off“ zu finden, schaltet das automatische hinzufügen von Abhängigkeiten aus dem Quellpaket komplett aus. Jedoch ist hier höchste Vorsicht geboten da man so sämtliche (auch unwichtig erscheinende) Abhängigkeiten in den Requires und BuildRequires äußerst genau angeben muß.
Eine weitere Möglichkeit bieten diese beiden macros (meist zusammen anzutreffen).
%define _requires_exceptions
Bedeutet: (schaltet benötigt/verlangt aus)
%define _provides_exceptions
Bedeutet: (gaukelt/täuscht dem Paket vor Datei sei im Paket enthalten)
Bsp.
%define _requires_exceptions libboost_program_options-gcc-mt-1_33_1.so.1.33.1\\|libboost_regex-gcc-mt-1_33_1.so.1.33.1\\|libboost_signals-gcc-mt-1_33_1.so.1.33.1 %define _provides_exceptions libboost_program_options-gcc-mt-1_33_1.so.1.33.1\\|libboost_regex-gcc-mt-1_33_1.so.1.33.1\\|libboost_signals-gcc-mt-1_33_1.so.1.33.1
Gibt also an das: „libboost_program_options-gcc-mt-1_33_1.so.1.33.1“
sowie „libboost_regex-gcc-mt-1_33_1.so.1.33.1“ und „libboost_signals-gcc-mt-1_33_1.so.1.33.1“
in dem Paket enthalten seihen (bzw. sind) und das nach diesen Dateien nicht als Abhängigkeiten gesucht werden soll.
Die einzelnen Dateien werden hier jeweils durch „\\|“ getrennt.
Einzelne „spec helpers“ deaktivieren. Auch das kann in bestimmten Situationen sinnvoll sein, ich selber habe es (glaube ich) jedoch noch nie gebraucht.
„spec helpers“ Wert: Beschreibung(grob übersetzt):
export DONT_CLEANUP=1 Entfernen Sie nicht Backup-und nutzlose Dateien \\ export DONT_CLEAN_PERL=1 Entfernen Sie nicht einige nicht benötigt perl Dateien (. Packlist, etc.) \\ export DONT_COMPRESS=1 Komprimiert nicht Manpages und Info-Dateien in bz2 \\ export DONT_STRIP=1 „strip"en Sie nicht Objektdateien und ausführbare Dateien \\ export DONT_RELINK=1 Relativierung von nicht symlinks \\ export DONT_SYMLINK_LIBS=1 Erstellen Sie kinen Symlink der Bibliothek \\ export DONT_GPRINTIFY=1 Nicht ersetzen durch echo grpintf in Initskript \\ export DONT_FIX_PAMD_CONFIGS=1 Regeln Sie nicht /lib für /lib64 in PAM configs \\ export DONT_REMOVE_INFO_DIR=1 Entfernen Sie nicht /usr/share/info/dir/ \\ export DONT_FIX_MO=1 Regeln Sie nicht einige Übersetzungen \\ export DONT_TRANSLATE_MENU=1 Übersetzen Sie den Menüabschnitt vom alten Entwurf nicht zum neuen
An dieser Stelle betrachten wir lediglich die Macros des Abschnitt 1, Beschreibung.
Dieses Macro erlaubt die Verknüpfung eines Macros mit einem Wort, einer Zahl, oder einer Funktion. Diese Eigenschaft nutzt man am Anfang der Spec-Datei zur Definition des Programmnamens, der Version, und der Ausgabe (Releasenummer).
Das Gleiche gilt für Bibliotheken und mehr aber das besprechen wir später.
%define name cwallpaper %define version 0.3 %define release %mkrel 1
Die Spec-Datei sollte immer mit diesen 3 Zeilen beginnen. Dies ist zwar nicht verbindlich aber eine gute Sitte. Außerdem ist es bei PCLinuxOS Standard und somit eine eiserne Regel für PCLinuxOS konforme RPMs. Macros vereinfachen das Schreiben von Spec-Dateien, helfen Fehler zu vermeiden, und erlauben ein einfaches und effizientes updaten: z.B. wird der Programmname, Versions- und Ausgabenummer (Releasenummer) nur einmal am Anfang der Spec-Datei definiert und wird anschließend über das Macro %name, %version bzw. %release aufgerufen.
Diese Funktion liest automatisch das zuvor erstellte .rpmmacros Dokument und fügt die Endsilbe an den Namen des RPM an.
Diese Funktion ersetzt den am Anfang der Spec-Datei definierten Namen unter %name, oder alternativ %{name}
Diese Funktion ersetzt die am Anfang der Spec-Datei definierte Version unter %version, oder alternativ %{version}
Diese Funktion ersetzt die am Anfang der Spec-Datei definierte Ausgabe unter %release, oder alternativ %{release}. Macros können in diesen 2 Notationen
mit oder ohne „{}“ geschrieben werden, beide Versionen sind und funktionieren gleichwertig.
Diese Funktion wird benutzt, um den Verzeichnispfad der in der Datei .rpmmacros definiert wurde aufzurufen. Dieses Macro wird benutzt um dem System das Verzeichnis zur Erstellung des RPMs mitzuteilen.
Der erste Abschnitt „Beschreibung“ ist damit abgeschlossen und wir betrachten nun den zweiten Abschnitt „Bauanleitung“.
http://mypclinuxos.com/doku.php/rpm-how-to:spec-files-3
Hier findet das eigentliche RPM Bauen in der Pseudoumgebung statt. Dieser Vorgang wird über Macros gesteuert, welche eine korrekte RPM-Erstellung gewährleisten. Hierbei wird nichts installiert und einige Verzeichnisse existieren noch nicht einmal (Anmerkung: Einige Verzeichnisse werden erst durch die Installation des fertigen RPMs erstellt und müssen daher in der Spec definiert werden). Wir betrachten nun die Bauanleitung unserer Anwendung.
Und los geht's!
%description
Cwallpaper is a GUI front end for wallpaper utilies such as xsetroot.
%prep
%setup -q
%build
%{configure} --prefix=%{_prefix}
%{__make} %{?_smp_mflags} %{?mflags}
%install
%{__make} %{?mflags_install} DESTDIR=$RPM_BUILD_ROOT install
%clean
test "x$RPM_BUILD_ROOT" != "x/" && rm -rf $RPM_BUILD_ROOT
%post
/sbin/ldconfig
%postun
/sbin/ldconfig
Dieses Macro kann eine detailierte Beschreibung Deiner Anwendung enthalten. Es muss vorhanden sein auch wenn es hier nicht mehr als in der Summary im ersten Abschnitt der Spec-Datei zu sagen gibt. %description kann genauso wie Summary mehrfach (für verschiedene Sprachen) angegeben werden.
Bsp.:
%description English description for the program %description -l de deutsche Beschreibung für Programm
Das prep Macro, aus dem Englischen prepare=vorbereiten, löscht eventuell vorhandene ältere Dateien im Verzeichnis ~/RPM/BUILD, eine Grundvoraussetzung zur erfolgreichen RPM-Erstellung. (Übrigens, das Verzeichnis ~/RPM/BUILD wird auch Bauverzeichnis genannt, welches im Gegensatz zum buildroot-Verzeichnis in dem die Pseudo-Installation stattfindet).
Diese Funktion extrahiert alle Dateien aus dem Quelltext (Archiv, Quellpaket, Quelltarball) und legt diese im BUILD Verzeichnis ab. Für den Fall das der Name des Quellverzeichnisses innerhalb des Quelltarballs dem des Quelltarballs entspricht ist die folgende Einstellung ausreichend:
%setup -q
(das -q steht für quiet zu deutsch still, das heißt es werden keine Meldungen ausgegeben!). *Ist hingegen der Name des Quellverzeichnisses ein anderer als das Quellverzeichnisses (das Quellverzeichnisses beinhaltet oft nicht die Versionsnummer) dann muss der folgende Eintrag gewählt werden:
*(Der Verzeichnisname im gepackten Quelltarball ist manchmal anders als Quelltarballname selbst)
%setup -q -n NameDesQuellverzeichnisses''
Weitere Optionen können sein:
# -q : Lassen Sie „quiet" mit minimalem Ausgang laufen # -n name : Nennen Sie das Verzeichnis als Name # -a num : Packen Sie nur Quellpaket aus, nachdem Sie das Verzeichnis geändert haben # -b num : Packen Sie nur Quellpaket aus, bevor Sie das Verzeichnis ändern # -c : Verzeichnis erstellen vor dem entpacke # -D : Vor dem Auspacken löschen Sie das Verzeichnis nicht # -T : Archiv nicht entpacken
Diese Funktion beginnt den eigentlichen Bauprozess (z.B. configure und make)
Dies ist die normale ./configure Funktion die zur RPM-Erstellung aus Quellcode verwendet wird. Varianten dieser Funktion können %{configure} oder auch %configure2_5x sein, benutze die Variante die deinem Paket entspricht. Diese Funktionen können mit Argumenten erweitert werden, z.B. - - prefix ist ein Argument zur Spezifizierung des Installationspfads ( siehe dazu auch %{_prefix} Macro). Alle Argumente sind in der configure Datei des Quellcodes aufgeführt.
Dies ist der make Befehl der die gleichen Argumente wie der normale make Befehl akzeptiert. Eine Variante dieser Funktion ist %{make} welches das Setzen von zusätzlichen flags im Bauprozess erlaubt.
Diese Funktion beginnt den Installationsprozess. Direkt nach %install sollte auch nochmal rm -rf %buildroot ausgeführt werden.
Die make install Funktion führt den Installationsprozess aus. Varianten dieser Funktion sind %make install und %{_make} install und alle erlauben das Hinzufügen von Bedingungen. Zum Beispiel gibt die Bedingung DESTDIR=$RPM_BUILD_ROOT den Ort des Installationsprozesses an, welches in unserem Beispiel nicht notwendig ist aber manchmal nützlich sein kann.
Genau wie %makeinstall nur setzt destdir automatisch auf %buildroot.
Ein Menüeintrag kann man mittels:
mkdir -p $RPM_BUILD_ROOT%{_datadir}/applications
cat > $RPM_BUILD_ROOT%{_datadir}/applications/%{name}.desktop <<EOF
[Desktop Entry]
Encoding=UTF-8
Name=%{name}
Comment=%{summary}
Exec=%{name}
Icon=%{name}
Terminal=false
Type=Application
X-KDE-SubstituteUID=true
X-KDE-RootOnly=true
Categories=[[http://maik3531.de/pclos2007/sonstiges/RPM-Script/categories-PCLinuxOS|Liste möglicher Categories]] ;
EOF
z.B. nach dem Macro „%install“ angeben, dabei müssen aber folgende eintrage unter „%post“ und „%postun“ vorhanden sein.
„%{update_menus},%{clean_menus}"
Um existierende Menüs nur zu bearbeiten kann man desktop-file-install verwenden.
Bsp.:
desktop-file-install \
--remove-key='Encoding' \
--vendor ''\
--dir %{buildroot}%{_datadir}/applications %{buildroot}%{_datadir}/applications/*
Dazu muss man aber das Paket „desktop-file-install“ sowohl bei BuildRequires: (also benötigt für die Erstellung) eingetragen haben und es muss natürlich auch installiert sein. Auch hier sind wieder unter %post und %postun Einträge nötig, Siehe unten „Beispiel“ bei %post und %postun.
Für die Argumente hier (Beispiel: MimeType) gibt es auch wieder verschiedene Möglichkeiten.
Bsp.:
--add-mime-type="%{mimetype}"
oder
MimeType=%{mimetype};
In KDE4 werden die MimeType Einträge auch wieder anders eingetragen als Beispiel hierfür:
# Associate File with MimeType (the KDE4/Gnome way)
mkdir -p $RPM_BUILD_ROOT%{_datadir}/mime/packages
cat > $RPM_BUILD_ROOT%{_datadir}/mime/packages/%{name}.xml << EOF
<?xml version="1.0"?>
<mime-info xmlns="http://www.freedesktop.org/standards/shared-mime-info">
<mime-type type="%{mimetype}">
<comment>%{name} file</comment>
<glob pattern="*.ext1"/>
<glob pattern="*.ext2"/>
<glob pattern="*.ext3"/>
</mime-type>
</mime-info>
EOF
während der selbe Eintrag unter KDE 3 bisher so ausgesehen hat:
# Associate File with MimeType (the KDE3 way)
%define old_kde_mime $RPM_BUILD_ROOT%{_datadir}/mimelnk/%{mimetype}.desktop
mkdir -p $RPM_BUILD_ROOT%{_datadir}/mimelnk/application
cat > %old_kde_mime << EOF
[Desktop Entry]
Type=MimeType
Comment=%{name} file
MimeType=%{mimetype}
Patterns=*.ext1;*.ext2;*.ext3;
EOF
Das sollte aber erst einmal reichen an dieser Stelle und somit gehen wir zum nähsten Thema.
Diese Funktion bereinigt nach der RPM Erstellung das buildroot Verzeichnis. Sollte die Erstellung nicht gelingen dann wird das buildroot Verzeichnis nicht bereinigt und das muss man dann selbst machen. Als Alternative kann man diesen Vorgang auch in das oben beschrieben %install Macro eintragen.
Bsp.:
%clean
[ "%{buildroot}" != "/" ] && rm -rf %{buildroot}
Bsp.: 2
%clean rm -rf $RPM_BUILD_ROOT
An dieser Stelle können zusätzliche scriptlets (scriptlets sind Ereignisse die Sie nach der RPM-Installation auf dem Rechner starten möchten) eingetragen werden. Bitte mindestens die im Beispiel aufgeführte Zeile eintragen, es sei denn Sie sind ein begnadeter Paketbäcker und wissen was Sie tun…
Bsp.:
%post %update_menus %update_desktop_database &> /dev/null ||: %update_mime_database &> /dev/null ||:
Bsp.: 2
%post -n %libname -p /sbin/ldconfig
An dieser Stelle können De-Installations scriptlets eingetragen werden. Bitte auch hier mindestens die im Beispiel aufgeführte Zeile eintragen, es sei denn Sie wissen, was Sie tun.
Bsp.:
%postun %clean_menus'' %clean_desktop_database &> /dev/null ||:'' %clean_mime_database &> /dev/null ||:''
Bsp.: 2
%postun -n %libname -p /sbin/ldconfig''
Prefix ist der vorgegebene Ort zur Lagerung der ausführbaren (executables), Bibliotheken, und anderer Dateien in Deinem System. Diese Funktion wird oft mit configure verwendet um, falls der Quellcode das zulässt, verschiedene Installationsorte zu definieren (Der Standard in PCLinuxOS ist /usr/ während andere Distributionen z.B. /usr/local/ nutzen).
Diese Funktion gibt den Ort des Installationsprozesses an. Benutze diese Funktion wenn Du Zugriff auf eine der installierten Dateien oder zusätzliche Dateien aus anderen Quellen benötigst. (Dies wird im Fortgeschrittenen Teil der Anleitung besprochen.)
Diese Funktion gibt den Ort des Quellcodes nach der Extraktion aus dem ursprünglichen tarball an. Benutze diese Funktion wenn Sie Zugriff auf eine bestimmte Datei des BUILD Verzeichnisses benötigen.
An dieser Stelle wird die gesamte Information der erstellten Dateien aufgeführt.
%files
%defattr(-, root, root)
%{_bindir}/cwallpaper
%{_datadir}/cwallpaper/*
%changelog
* Wed Aug 15 2007 Gettinther <gettinther@gmail.com> 0.3-1pclos_tinyme2007
- rebuild for pclos2007
- Dependency on cwallpaper-update script added by Kdulcimer
An dieser Stelle werden alle Dateien die Dein RPM installiert aufgelistet.
Den Inhalt dieser Liste kann man auf einfache Weise erzeugen indem man das RPM mit einem leeren %files Eintrag baut (man benötigt %files und %defattr).
Der Erstellungsversuch wird mit einer Meldung über gefundene aber nicht installierte Dateien fehlschlagen. Nun einfach den Inhalt dieser Meldung kopieren und in die Spec-Datei einfügen, fertig.
Bsp.:
%files
%defattr(-,root,root)
%{_bindir}/*
%{_datadir}/%{name}/*
%{_datadir}/applications/%{name}.desktop
%{_datadir}/mime/packages/%{name}.xml
%{_datadir}/mimelnk/%{mimetype}.desktop
Es folgt eine Liste der häufigsten Macors für Verzeichnis-Variablen (Pfadangaben):
%{_prefix} /usr
%{_exec_prefix} /usr
%{_bindir} /usr/bin
%{_libdir} /usr/lib
%{_libexecdir} /usr/lib
%{_usrsrc} /usr/src
%{_menudir} /usr/lib/menu
%{_sbindir} /usr/sbin
%{_sharedstatedir} /usr/com
%{_includedir} /usr/include
%{_oldincludedir} /usr/include
%{_sysconfdir} /etc
%{_datadir} /usr/share
%{_mandir} /usr/share/man
%{_docdir} /usr/share/doc
%{_defaultdocdir} /usr/share/doc
%{_infodir} /usr/share/info
%{_iconsdir} /usr/share/icons
%{_miconsdir} /usr/share/icons/mini
%{_liconsdir} /usr/share/icons/large
%{_gamesbindir} /usr/games
%{_gamesdatadir} /usr/share/games
%{_localstatedir} /var/lib
Diese Funktion definiert die vorgegebenen Eigenschaften (Zugriffsrechte) der Dateien wenn nicht anderweitig in der Dateienliste beschrieben (bitte wie im Beispiel beschrieben belassen).
In unserem Beispiel fehlt diese oft gebrauchte Funktion. Sie beschreibt die Liste der Quellcodedateien, z.B. Lizenzbestimmungen, die in das RPM kopiert werden sollen. Ein typischer Eintrag sieht z.B. so aus:
%doc AUTHORS COPYING ChangeLog INSTALL NEWS README TODO
Hier kommt die Information zu (wer, wann, und warum) hin. Bitte unbedingt die im Beispiel gezeigte Formatierung beibehalten.
%CHANGELOG * Wochentag Monat Tag Jahr Username <E-Mail@Adresse.de> - was wurde geändert/gemacht
Der Vollständigkeit halber zeige ich noch eine zweite Möglichkeit in den CHANGELOG zu schreiben. Jedoch wird diese Art zumindest bei PCLinuxOS als unzulässig! gewertet. Also gewöhnen Sie es sich erst gleich richtig an, nur das Sie es mal gesehen haben.
%define date %(echo `LC_ALL="C" date +"%a %b %d %Y"`)
%CHANGELOG
* %{date} User <User@e-mail.de>
- first Version
Na, war doch gar nicht so schwer, oder? Jetzt muss das RPM nur noch kompiliert werden.
Die Kompilierung ist nun wahrscheinlich der einfachste Teil, da der Quellcode und die „wundervolle“ Spec-Datei bereits vorliegen.
Anmerkung: Bitte sicherstellen das der Quellcode (das *.tar.. Archiv) im Verzeichnis ~/RPM/SOURCES und die Spec-Datei im Verzeichnis ~/RPM/SPECS vorliegen.
Als nächstes öffnen wir eine Konsole im Spec Verzeichnis ~/RPM/SPECS und geben (nicht als root) sondern als normaler User!, den folgenden Befehl ein:
rpmbuild -ba NameDeinerSpecDatei.spec
Das RPM wird nun vor Deinen eigenen Augen erstellt!
Und da Du diese Anleitung sorgfältig gelesen und befolgt hast, sogar ohne einen einzigen Fehler, Du bist ein Genie!
In Abhängigkeit des Quellcodes befinden sich nach Fertigstellung die erstellten RPMs im Verzeichnis „~/RPM/i586“ oder „~/RPM/noarch“ und das neue SRPM (source rpm) im Verzeichnis „~/RPM/SRPMS“.
Und ist das schon alles? Wenn Sie Glück haben und das RPM funktioniert, ja. Falls es nicht funktionieren sollte, müssen Sie die Spec-Datei abändern oder den Quellcode im tarball dahingehend anpassen das er mit Ihrem System funktioniert. Man erstellt einen sogenannten „patch“. Patches und weitere Funktionen für fortgeschrittene Paketbäcker werden später besprochen.
Selbst wenn die Kompilierung erfolgreich war, muss das RPM installiert und jedes einzelne Element überprüft werden um sicherzustellen, das es wie geplant funktioniert. Und wir appellieren ganz eindringlich an Dein Verantwortungsgefühl, denn das von Dir erstellte RPM wird evtl. an andere zur Nutzung weitergegeben. Und außerdem bist Du gerade ein „Pfleger“ für dieses PCLinuxOS Paket geworden. Herzlichen Glückwunsch! Du hast ein einfaches RPM gebaut und im nächsten Schritt besprechen wir das Teilen eines RPMs.
Beim Arbeiten mit RPMs ist es manchmal notwendig die Bibliotheken von den übrigen Dateien zu trennen (englisch: split). Gründe hierfür sind zum einen die Dateigröße des RPMs gering zu halten und zum anderen den alleinigen Gebrauch der Bibliotheken zu ermöglichen. Die Methode des splitting ist auch sinnvoll um potentiell unnötige Teile auszuschließen und diese als Plugin RPM anzubieten. Desweiteren sollten Entwicklungsdateien immer abgetrennt werden.
Die Erstellung eines jeden abgetrennten RPMs von Bibliotheken, Entwickler- und anderen Dateien erfordert das Aufsetzen von:
Der Bauanleitungsabschnitt der Spec Datei (%Install usw.) bleibt, unabhängig von der Anzahl der Unterabschnitte, unverändert.
Zuerst müssen die Namen der Bibliotheken erstellt werden und wir beginnen mit der Definition der Bibliothek-Macros.
%define major 1
%define libname %mklibname %{name} %major
%define libnamedev %mklibname %{name} %major -d
Diese 3 Zeilen sind die Standardmethode in PCLinuxOS zur Definition von Bibliotheksnamen. Sie erstellen automatisch die richtigen Namen und Du solltest sie genau so verwenden (sie sind Deine Freunde).
Diese Macro wird zur Behandlung künftiger Inkompatibilität benötigt. Es erlaubt die Benutzung zweier Bibliotheken mit identischem Namen, aber different major im Fall einer API Änderung.
Hierdurch können ältere Programme die alte und neuere Programme die neue Bibliothek benutzen.
Dieses Macro nutzt die Information der ihm folgenden Argumente (%{name} %{major} -d (-d steht für devel, Entwicklung) zur Erstellung der Bibliotheknamensbasis.
Die RPMs des folgenden Beispiels sind:
Die SRPM, die diese Spec-Datei beinhalten, können hier heruntergeladen werden:
%define name e_dbus
%define version 0.1.0.002
%define release %mkrel 1
%define major 1
%define libname %mklibname %{name} %major
%define libnamedev %mklibname %{name} %major -d
Summary: Basic convenience wrappers around dbus to ease integrating dbus with EFL based applications
Name: %{name}
Version: %{version}
Release: %{release}
License: BSD
Group: Graphical desktop/Enlightenment
URL: http://get-e.org/
Source: %{name}-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-buildroot
BuildRequires: ewl-devel
%description
This is the start of some basic convenience wrappers around dbus to ease integrating dbus with EFL based applications.
%package -n %libname
Summary: Libraries for the %{name} package
Group: System/Libraries
%description -n %libname
Libraries for %{name}
%package -n %libnamedev
Summary: Headers and development libraries from %{name}
Group: Development/Other
Requires: %libname = %{version}
Provides: lib%{name}-devel = %{version}-%{release}
Provides: %name-devel = %{version}-%{release}
%description -n %libnamedev
%{name} development headers and libraries
%prep
%setup -q
%build
%{configure} --prefix=%{_prefix}
%{__make} %{?_smp_mflags} %{?mflags}
%install
%{__make} %{?mflags_install} DESTDIR=$RPM_BUILD_ROOT install
%post -n %libname -p /sbin/ldconfig
%postun -n %libname -p /sbin/ldconfig
%clean
rm -rf $RPM_BUILD_ROOT
%files
%defattr(-,root,root)
%doc AUTHORS COPYING README
%{_bindir}/e_dbus*
%files -n %libname
%defattr(-,root,root)
%{_libdir}/lib*.so.*
%files -n %libnamedev
%defattr(-,root,root)
%{_libdir}/pkgconfig/*
%_libdir/lib*.so
%_libdir/lib*.a
%_libdir/lib*.la
%{_includedir}/*.h
%changelog
* Thu Jul 12 2007 Gettinther <gettinther@gmail.com> 0.1.0.002-1pclos_tinyme
- Updated to version 0.1.0.002
Nachdem wir die Namen eines jeden zu bildenden Unterpakets definiert haben können wir nun die beiden Abschnitte Zusammenfassende Beschreibung und Dateien erstellen. Ein jedes Unterpaket muss seine eigene Version dieser beiden Abschnitte besitzen und diese sind nicht so kompliziert wie die Abschnitte des eigentlichen Pakets.
Hier steht der Paketname der in diesem Unterabschnitt definiert wurde und normalerweise sollte hier -n %libname stehen. Das -n sagt %package den zuvor definierten Namen %libname zu benutzen.
Wird für jeden Unterabschnitt mit den selben Regeln wie im Hauptabschnitt gebraucht. Kann genau wie %description in mehreren Sprachen angegebenen werden. (Siehe: %description) Summary sollte nicht länger als 79 Zeichen lang sein.
Wird für jeden Unterabschnitt mit den selben Regeln wie im Hauptabschnitt gebraucht. Wie schon im Hauptabschnitt, können auch hier zusätzliche Abhängigkeiten und Bedingungen mittels der Zeilen BuildRequires: und Requires: spezifiziert werden.
Eine Beschreibung des Unterabschnitts, was er macht und wozu es ihn gibt.
Die Struktur dieses Abschnitts entspricht dem Hauptteil mit der Ausnahme das nach dem %file der Unterabschnittsname steht, für gewöhnlich %file -n NameDesUnterabschnitts.
Okay! Anhand des obigen Beispiels haben wir gesehen wie Bibliotheken und Entwicklungsdateien zum eventuellen Gebrauch von anderen Anwendungen abgetrennt werden können. Wir haben gelernt RPMs zu erstellen und diese aufzuteilen.
Im nächsten Schritt betrachten wir Spec-Dateien mit mehrfachen Quellen…..
Spec-Dateien mit mehrfachen Quellen Anmerkung: Dieser Abschnitt ist noch nicht Vorhanden. Es ist aber gut möglich das er hinzugefügt wird.
Kurz zusammengefasst kann man einen Patch wie folgt erstellen:
Entpacken wie im oberen Teil beschrieben oder komfortabler, mit Hilfe der Servicemenüs der Pakete „K-Rpm2Info“ oder „rpmxdgtool“.
rpmbuild -bp ~/RPM/SRPMS/xxx.spec
bewirkt %prep ausführen
und unter „~/RPM/BUILD/…“ Datei „1“ zu „1.orig“ kopieren. Dann die Datei „1“ anpassen, wobei sich die „1“ auf jede Datei beziehen kann.
Bsp.:
cp /home/Benutzername/RPM/BUILD/Programmname/"1" /home/Benutzername/RPM/BUILD/Programmname/"1.orig"
Nun also die Datei 1 so anpassen wie der Patch später die originale Dateien ändern soll. Danach wechseln wir in das BUILD Verzeichnis und werden da zu Root.
cd /home/Benutzername/RPM/BUILD su Passwort...
Nun noch folgendes eingeben:
$ gendiff /home/Benutzername/RPM/BUILD/xxx/ .orig >/home/Benutzername/Desktop/testpatch.patch
Den so erstellten Patch nach “/home/Benutzername/RPM/SOURCES/“ kopieren und mit z.B. '%patch -p1' in der Spec angeben.
Bsp.:
...
Release: %{release}
Source0: %{name}-%{version}.tar.bz2
Patch0: testpatch.patch # <-- Ihre Patch Datei (z.B. testpatch.patch)''
...
%setup -q
%patch0 -p1
Man kann auch einen Patch erstellen mittels diff -u alt neu > patch
K-Rpm2Info
rpmxdgtool
KRPM-Builder
RPMBau-de / RPMBau-en (Script)
RPMBau-de Script kann nach dem downloaden ausführbar gemacht und angeklickt werde. Es basiert auf kdialog bzw. gdialog, wer aber kein KDE installiert hat sollte unbedingt die Liste der zu installierenden Pakete im Script anpassen da sonst das Komplette KDE nachinstalliert wird.
Wenn eine englische PCLinuxOS Version installiert ist funktioniert das „-de“ Script nicht, „genau so wie andersrum (zumindest bei addpkg)“
addpkg-de / addpkg-en (Script)
Mit addpkg kann man im Falle einer Fehlermeldung einfach “addpkg Specname.spec“ ausführen und die fehlenden Abhängigkeiten werden installiert und in eine Datei zu Prüfung, wenn gewünscht geschrieben. Auch bei einzelnen RPMs kann man fehlende Abhängigkeiten mit “addpkg rpmname-pclos2007.i586.rpm“ installieren. Das Script addpkg sollte nach dem download entpackt, ausführbar gemacht werden und unter „/usr/local“ abgespeichert werden.
Ergänzung: addpkg sowie das RPMBau-de Script ist in pkgutiles-de-servicemenu enthalten sowie weitere sinnvolle Servicemenüs.
http://www.mandrivauser.de/doku/doku.php?id=advanced:paketbau
http://mandrivauser.de/viewtopic.php?id=16156
http://www.linuxhaven.de/dlhp/HOWTO/DE-RPM-HOWTO.html#toc1
http://archiv.tu-chemnitz.de/pub/2006/0178/data/vortrag.html
http://www.tu-chemnitz.de/docs/lindocs/RPM/
http://www.selflinux.org/selflinux/html/software_installation02.html
http://jan.kneschke.de/projects/rpm-packaging.pdf
http://www.tu-chemnitz.de/docs/lindocs/max-rpm.pdf
http://de.opensuse.org/Paketverwaltung/Abhängigkeiten
http://www.fedorawiki.de/index.php/Paketverwaltung
http://apt-rpm.org/reposetup-native.shtml
http://wiki.mandriva.com/en/Development/Packaging/Problems#build_errors
http://linuxwiki.de/RPM/BuildAlsUser#head-5a972414df3819fc50ef23200acbf4122c16fdaf
http://docs.fedoraproject.org/drafts/rpm-guide-en/ch-advanced-packaging.html