RPM-Paketbau-Anleitung

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!




  • INTRO

Was ist ein RPM?

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)


Warum RPMs bauen?

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.

Für wen ist diese Anleitung gedacht?

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.

Wer kann RPMs bauen?

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.

Was wird zum RPM-Bau benötigt?

  • Bitte zuerst die PCLinuxOS CD runterladen und auf einer freien Partition installieren.
  • Dann das Menu öffnen und in Anwendungen → System → Terminals → Terminal (Systemverwaltungsmodus)starten
  • Auf Anfrage das Root-Passwort eingeben danach folgendes eingeben: kwrite /etc/apt/sources.list
  • Nach öffnen des Editors, runter scrollen und die Stelle mit #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
  • Das Dokument speichern und kwrite schließen.

Konfiguration des Systems

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:

  • pkgutils

oder für KDE 4

  • pgkutils-kde4

oder für den Thunar Dateimanager

  • pkgutils-thunar

Abschließend werden diese über Vormerken → Ausführen installiert. Fertig!




  • SETUP

System zur RPM Erstellung vorbereiten

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)

Anmerkung:

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“!




  • SPEC DATEI 1

Einleitung

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

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.

Aus dem SRPM extrahieren

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:

  • PCLinuxOS
  • Mandriva
  • Fedora
  • Suse
  • Andere

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.

Die Spec-Datei selbst schreiben

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.

Übersicht einer Spec-Datei

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)



  • SPEC DATEI 2

Spec Datei Übersicht

Die Spec-Datei besteht aus 3 Abschnitten:

  1. die zusammenfassende Beschreibung
  2. die Bauanleitung
  3. die Dateien

(es gibt noch den changelog aber das ist kein eigenständiger Abschnitt)

1. Abschnitt: Beschreibung

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.

  • Summary: Kurzbeschreibung der Anwendung (eine ausführliche Beschreibung wird unter %description eingetragen
  • Name: Name der Anwendung. Dieser Name wird der Name des RPM Pakets und muss mit dem Namen des Quelltextes übereinstimmen
  • Version: aktuelle Versionsnummer. Die Versionsnummer muss mit der des Quelltextes übereinstimmen.
  • Release: Diese Nummer wird nach jeder RPM Korrektur um eins erhöht und entspricht der Anzahl der Einträge im %changelog
  • License: Die Lizenz unter der der Quelltext veröffentlicht wird. Die Lizenz muss immer im Quelltext enthalten sein.
  • Group: Group definiert die Art der Anwendung, z.B. Grafik, Internet, etc. Eine Group Liste findet man im linken Panel von Synaptic nach der Auswahl von „Section“. Für den Group Eintrag bitte nur Namen verwenden die bereits in Synaptic vorhanden sind.
  • Source: Source ist der Name des Quelltextes der in ein RPM umgebaut wird. Die bevorzugte Quelltext Komprimierung ist tar.bz2. Natürlich gibt es auch andere Komprimierungsmöglichkeiten (in unserem Beispiel tar.gz), jedoch ist für eine Aufnahme in das PCLinuxOS Repository die tar.bz2 Kompression Pflicht!
  • Buildroot: buildroot ist der Name des Verzeichnisses in dem der vorübergehende Bau des Pakets stattfindet. Das ist im Moment noch nicht wichtig.
  • URL: Pfad zum Quelltext
  • BuildRequires & Requires: An dieser Stelle die Abhängigkeiten (Bauanforderung) zum erfolgreichen RPM Bau eintragen. Die erste Adresse zur Auffindung von Abhängigkeiten ist der Abschnitt 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 nicht

ausschließ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.


Zusatz:

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.

Abhängigkeiten ausschalten/aushebeln

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

Macros

An dieser Stelle betrachten wir lediglich die Macros des Abschnitt 1, Beschreibung.

%define

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.

%mkrel

Diese Funktion liest automatisch das zuvor erstellte .rpmmacros Dokument und fügt die Endsilbe an den Namen des RPM an.

%name

Diese Funktion ersetzt den am Anfang der Spec-Datei definierten Namen unter %name, oder alternativ %{name}

%version

Diese Funktion ersetzt die am Anfang der Spec-Datei definierte Version unter %version, oder alternativ %{version}

%release

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.

%_tmppath

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




  • SPEC DATEI 3

2. Abschnitt: Bauanleitung

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

%description

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

%prep

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).

%setup

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

%build

Diese Funktion beginnt den eigentlichen Bauprozess (z.B. configure und make)

%configure

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.

%make

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.

%install

Diese Funktion beginnt den Installationsprozess. Direkt nach %install sollte auch nochmal rm -rf %buildroot ausgeführt werden.

%makeinstall

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.

%makeinstall_std

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.

%clean

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

%post

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

%postun

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}

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).

$ RPM_BUILD_ROOT

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.)

$ RPM_BUILD_DIR

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.




  • SPEC DATEI 4

3. Abschnitt: Dateien

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

%files

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

%defattr(-, root, root)

Diese Funktion definiert die vorgegebenen Eigenschaften (Zugriffsrechte) der Dateien wenn nicht anderweitig in der Dateienliste beschrieben (bitte wie im Beispiel beschrieben belassen).

%doc

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

%changelog

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.




  • COMPILE

Kompilierung eines RPMs

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.




  • Splitting

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:

  • Eine neue zusammenfassende Beschreibung
  • Einen neuen Dateiabschnitt

Der Bauanleitungsabschnitt der Spec Datei (%Install usw.) bleibt, unabhängig von der Anzahl der Unterabschnitte, unverändert.

Erstellung von Bibliotheksnamen

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).

%major

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.

%mklibname

Dieses Macro nutzt die Information der ihm folgenden Argumente (%{name} %{major} -d (-d steht für devel, Entwicklung) zur Erstellung der Bibliotheknamensbasis.

e_dbus Beispiel

Die RPMs des folgenden Beispiels sind:

  • e_dbus-0.1.0.002-1pclos_tinyme2007.i586.rpm
  • libe_dbus1-0.1.0.002-1pclos_tinyme2007.i586.rpm
  • libe_dbus1-devel-0.1.0.002-1pclos_tinyme2007.i586.rpm

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.

Abschnitt: Zusammenfassende Beschreibung

%package

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.

Summary

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.

Group

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.

%description

Eine Beschreibung des Unterabschnitts, was er macht und wozu es ihn gibt.


Datei Abschnitt

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.


Patch erstellen

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


Tools

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.


 
rpm-bau.txt · Zuletzt geändert: 2014/03/05 22:25 (Externe Bearbeitung)
Recent changes RSS feed Creative Commons License Driven by DokuWiki Made on Mac