Paketbau/SUSE-Paketkonventionen/Bestimmte Pakete

aus openSUSE, der freien Wissensdatenbank

10. Bestimmte Pakete

10.1. GTK+- und GNOME-Pakete

Dieser Abschnitt beschreibt, wie GTK+- und GNOME-Pakete unter SUSE Linux/openSUSE erstellt werden. Nachdem der erste Teil grundlegende Informationen enthält, folgen einige Unterabschnitte, die komplexere oder weniger grundsätzliche Fähigkeiten beschreiben, hauptsächlich: Gconf, die GStreamer-Registrierung und die verteilte MIME-Datenbank.

Es gibt die folgenden Grundregeln:

• GTK+ Version 1.x läuft aus. Es sollten, wann immer möglich, Pakete bevorzugt werden, die GTK+ Version 2.x nutzen.
• GTK+- und GNOME–basierte Bibliotheken, optional auch Anwendungen sollten den gleichen Prefix wie GTK+/GNOME selbst nutzen. Dies hilft dabei, Prefix-Kollisionen zu vermeiden. Bis openSUSE 10.2 war der Prefix /opt/gnome, ab openSUSE 10.3 ist er /usr. Es gibt einige Ausnahmen, bei denen die Dateien explizit unter /usr gespeichert werden mössen. Siehe Abschnitt 10.1.3, "Geteilte MIME-Infos".
  Gemäß dem FHS müssen Konfigurationsdateien unterhalb von /etc/opt/gnome und variable Daten unterhalb von /var/opt/gnome gespeichert werden, falls der Prefix /opt/gnome ist.
• GTK+-bezogene -devel-Pakete sollten in die RPM-Gruppe Development/Libraries/X11 eingeordnet weden. GNOME-bezogene -devel-Unterpakete sollten in die Gruppe Development/Libraries/GNOME einsortiert werden. Sowohl GTK+- als auch GNOME–bezogene Pakete, die die Teile der Bibliotheken enthalten, die zur Laufzeit benötigt werden, sollten in die Gruppe System/Libraries einsortiert werden. Die GNOME-Desktop-Pakete sollten in die Gruppe System/GUI/GNOME. Schlussendlich sollten die GTK+- und GNOME–bezogenen Anwendungen in eine passende Untergruppe von Productivity einsortiert werden.

Die Pakete, die für den Bau benötigt werden, müssen im BuildRequires Tag erwähnt werden, Abhängigkeiten werden dabei automatisch aufgelöst. Zwei Metapakete sind definiert: gtk2-devel-packages und gnome2-devel-packages, die beide im BuildRequires Tag aufgelistet werden können. Sie stehen stellvertretend für mehrere Pakete, die zur Kompilation von auf GTK+ 2.x und GNOME 2.x basierenden Paketen benötigt werden. Das Metapaket gnome2-devel-packages enthält lediglich Kernbibliotheken, einschließlich libgnomeprint, aber keine weniger grundlegenden Bibliotheken wie gnome-panel, vte und gail. Einige Andere Pakete, die lediglich zur Laufzeit aber nicht für den Bau gebraucht werden, sind ebenfalls enthalten, bspw. einige gdk-pixbuf-Lader, Schriftarten und Schriftartendatenbankenkonfigurationenen.

Die meisten GTK+- und GNOME-Pakete nutzen den Standarddreisatz aus configure, make und make install. Es reicht normalerweise aus, die richtigen Pfade über die configure-Optionen zu setzen; andere spezielle Aktionen zum finden von GTK+ und GNOME sind nicht nötig. Es ist hier also ähnlich wie bei den meisten anderen Paketen.

Die zugehörigen Teile der spec-Datei sehen für gewöhnlich in etwa so aus:

%build
%suse_update_config -f
CFLAGS="$RPM_OPT_FLAGS” \
./configure --prefix=/opt/gnome \
        --libdir=/opt/gnome/%_lib \
        --sysconfdir=/etc/opt/gnome \
        --localstatedir=/var/opt/gnome
make

%install
make DESTDIR=$RPM_BUILD_ROOT install

Beachten Sie auch, wie im obigen Beispiel üblicherweise die $RPM_OPT_FLAGS an configure übergeben werden. Beachten Sie außerdem, dass normalerweise das Makro %suse_update_config aufgerufen wird, um einiges automatisches Zeug zu aktualisieren.

Viele GNOME-Pakete nutzen Hilfsskripte oder Binärdateien, die im libexec-Verzeichnis installiert werden. Sie müssen dafür --libexecdir=/opt/gnome/lib/%{name} aufrufen, wobei %{name} normalerweise der Paketname ist. Hierbei wird lib an Stelle von %lib genutzt. Weitere Details finden Sie in Kapitel 4.1, "Biarch-Systeme". Die Konfiguration sind dann normalerweise etwa so aus:

./configure --libdir=/opt/gnome/%_lib \
            --libexecdir=/opt/gnome/lib/%{name} \
            [...]

Pakete, die GNOME-Applets bereitstellen, können class="literal">--libexecdir=/opt/gnome/lib/gnome-applet</code> nutzen. Dieses Verzeichnis ist für diese Applets serverviert.

Alle Anwendungen sollten eine .desktop-Datei installieren, um einen Menüeintrag zu definieren. Sie müssen für alle installierten Menüeinträge im %install-Abschnitt das Makro %suse_update_desktop_file aufrufen. Dieses typische Beispiel entstammt dem Paket planner:

%install
[...]
%suse_update_desktop_file %name Office ProjectManagement

Sprachspezifische Dateien (Lokalisierungen von Menüeinträgen, Meldungen, Hilfsinhalte, usw.) sollten in der Dateiliste mit dem zugehörigen %lang Tag markiert werden. Für diesen Zweck gibt es auch das Makro %find_lang, welches meist folgendermaßen eingesetzt wird:

%install
[...]
%find_lang %name

%files -f %{name}.lang
[...]

10.1.1. GConf

GNOME-Pakete nutzen oftmals die GConf-Konfigurationsdatenbank, welche aus Frot-End- und Back-End-Dateien besteht. In der Dateiliste befinden sich nur Front-End-Dateien. Back-End-Dateien werden während der Installation erstellt. Diese Fähigkeit wird genutzt, wenn ein Paket irgendeine Datei nach $sysconfdir/gconf installiert.

Um dies zu nutzen, sollte der Betreuer zuerst prüfen, ob die Applikation alle genutzten Schemata-Dateien nach $sysconfdir/gconf/schemas installiert. Die meisten Pakete machen dies, wobei es trotzdem einige fehlerhafte gibt.

Als nächstes muss das Paket so konfiguriert werden, dass es die Back-End-Dateien nicht innerhalb der %install-Phase erstellt, was folgendermaßen geschehen kann:

1. Durch das Hinzufügen der --disable-schemas-install-Option zu configure:
   ./configure --disable-schemas-install ...
2. Durch Nutzung der GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL-Variablen:
   export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1
   make install DESTDIR=$RPM_BUILD_ROOT
   unset GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL
3. Falls beides nicht funktioniert, muss das Paket manuell repariert werden.

Schlussendlich müssen die Back-End-Dateien im %post-Skript generiert werden. Vergessen Sie dabei nicht, die genutzten Pakete im PreReq Tag zu erwähnen.

Dieses Beispiel entstammt dem Paket epiphany. Es sind zwei Dateien, epiphany.schemas und epiphany-lockdown.schemas, in /etc/opt/gnome/gconf/schemas installiert. Das zugehörige %post-Skript sieht wie folgt aus:

PreReq:       gconf2 gnome-filesystem

%post
export GCONF_CONFIG_SOURCE=`opt/gnome/bin/gconftool-2 \
                               –get-default-source`
opt/gnome/bin/gconftool-2 –makefile-install-rule \
    etc/opt/gnome/gconf/schemas/epiphany.schemas >/dev/null
opt/gnome/bin/gconftool-2 –makefile-install-rule \
    etc/opt/gnome/gconf/schemas/epiphany-lockdown.schemas \
    >/dev/null

Die Back-End-Dateien werden im %postun-Skript nicht wieder entfernt. Dies ist ein Problem des Aufbaus von GConf. Seit SL 9.2 ist das Skript gconftool-rebuild verfügbar, welches genutzt werden kann, um die GConf-Datenbank von Grund auf neu zu bauen.

Es ist eine gute Angewohnheit, die .schemas-Dateien in der Dateiliste explizit einzutragen. Dies hilft dabei, Probleme nach einer Aktualisierung zu vermeiden. Sowohl die Dateiliste als auch das %post-Skript müssen aktualisiert werden, wenn eine neue .schemas-Datei erscheint und rpm warnt, falls nicht alle installierten Dateien in der Dateiliste erwähnt werden. Die Dateiliste des obigen Beispiels sollte wie folgt aussehen:

%files
[...]
/etc/opt/gnome/gconf/schemas/epiphany.schemas
/etc/opt/gnome/gconf/schemas/epiphany-lockdown.schemas

an Stelle von:

/etc/opt/gnome/gconf/schemas/*.schemas

10.1.2. GStreamer-Registrierung

Ein Multimediapaket kann sein eigenes Multimedia-Plug-In für GStreamer definieren. Diese Fähigkeit wird genutzt, wenn das Pakt irgendeine Datei nach /opt/gnome/%_lib/gstreamer-{version} installiert.

Dafür muss die GStreamer-Registrierung aktualisiert werden, um das Plug-in sichtbar zu machen. Dies sollte sowohl im %post- als auch im %postun-Skipt geschehen. Vergessen Sie nicht, die benutzten Werkzeuge im PreReq Tag zu erwähnen. Der zugehörige Code schaut dann wie folgt aus

PreReq:       /opt/gnome/bin/gst-register
[...]

%post
opt/gnome/bin/gst-register >/dev/null

%postun
opt/gnome/bin/gst-register >/dev/null

In neueren Versionen von openSUSE (ab 10.3) hat sich der Pfad geändert, GNOME ist nicht mehr unter /opt/gnome, sondern unter /usr/ installiert.

Pakete, mit Ausnahme des Pakets gstreamer, dürfen die Datei /var/opt/gnome/cache/gstreamer-{version}/registry.xml nicht enthalten. Falls diese von make install unter $RPM_BUILD_ROOT erstellt wird, dann ist dies ein Fehler und die Datei muss entfernt werden.

10.1.3. Geteilte MIME-Infos

Die Geteilte MIME-Info ist ein neuer Standard von freedesktop.org. Siehe www.freedesktop.org/Standards/shared-mime-info-spec. Er wird von neueren Versionen von GNOME genutzt.

Diese Fähigkeit wird genutzt, wenn ein Paket eine Datei nach $datadir/mime installiert und die Distribution das shared-mime-info-Paket enthält. Dieses Paket ist seit SL 9.2 Teil von SUSE Linux.

Die geteilte MIME-Datenbank befindet sich in /usr/share/mime. Seit SuSE Linux 9.3 können GNOME-pakete auch /opt/gnome/share/mime nuztzen (ab 10.3 befindet sich GNOME allerdings unter /usr).

Einige Pakete rufen update-mime-database während der Installation mit definiertem DESTDIR auf. Es gibt einen Fehler, der zum Paketieren der aktuellen MIME-Datenbank führen kann, an Stelle der Komponenten, auch wenn DESTDIR gesetzt ist. Am einfachsten lässt sich der Fehler umgehen, indem man die erstellten Dateien am Ende der %install-Sektion wieder entfernt. Grundsätzlich sind alle Dateien außer packages/*.xml erstellte Dateien und müssen entfernt werden. Das folgende Beispiel ist dem Paket planner entnommen:

%install
[...]
cd $RPM_BUILD_ROOT/opt/gnome/share/mime
rm -f XMLnamespaces aliases globs magic subclasses application/x-planner.xml
rmdir application

Es bleibt die Datei /opt/gnome/share/mime/packages/planner.xml übrig, um sie in das Paket aufzunehmen.

Schlussendlich muss die geteilte MIME-Datenbank noch in den %post- und %postun-Skripten aktualisiert werden. Vergessen Sie dabei nicht, die benötigten Pakete im PreReq Tag anzugeben. Die zugehörigen Code-Zeilen sehen etwa so aus:

PreReq:       shared-mime-info
[...]

%post
usr/bin/update-mime-database /opt/gnome/share/mime >/dev/null

%postun
usr/bin/update-mime-database /opt/gnome/share/mime >/dev/null

MIME-Typen können vom Paket nautilus getestet werden. Es reicht aus, dass zu testende Paket zu installieren, Nautilus zu starten und sich die Eigenschaften einer passenden Datei anzuschauen. Der installierte MIME-Typ sollte dort korrekt definiert sein.

Hinweis

/opt/gnome/share/mime wurde in SL 9.2 nicht unterstützt. Dies war der Grund dafür, warum GNOME-Pakete die zugehörigen Dateien nach /usr/share/mime verschoben haben. Dieser Hack ist überflüssig und kann entfernt werden. Er sah für gewöhnlich so aus:

%install
[...]
mkdir -p $RPM_BUILD_ROOT/usr/share
mv $RPM_BUILD_ROOT/opt/gnome/share/mime $RPM_BUILD_ROOT/usr/share

10.1.4. GNOME MIME Info

Ältere GNOME-Pakete nutzen mime-info für MIME-Typ-Definitionen. Sole MIME-Typen werden von neuen GNOME-Versionen nicht erkannt. Das Paket braucht auch shared-mime-info. Diese Fähigkeiten wird genutzt, wenn das Paket Dateien nach /opt/gnome/share/mime-info installiert. Falls es unter /usr/share/mime oder /opt/gnome/share/mime keine Dateien gibt, muss die shared-mime-info von mime-info erstellt werden. Siehe auch Kapitel 10.1.3, "Shared MIME Info".

Die Umwandlung kann entweder vom Skript mime-info-to-mime erledigt werden, das vom Paket shared-mime-info bereitgestellt wird und folgendermaßen in der %install-Sektion aufgerufen werden kann:

%install
[...]
DESTDIR=$RPM_BUILD_ROOT mime-info-to-mime

Oder falls das Kommando fehl schlägt, müssen die erstellten Dateien $RPM_BUILD_ROOT/usr/share/mime/packages/*.xml manuell bearbeiteten werden. Die korrigierten Dateien werden dem Paket normalerweise als Extraquellen hinzugefügt und in der %install-Sektion installiert. Dieses Beispiel entstammt dem Paket file-roller:

Source1:      file-roller.xml
[...]

%install
[...]
mkdir -p $RPM_BUILD_ROOT/usr/share/mime/packages
cp %{S:1} $RPM_BUILD_ROOT/usr/share/mime/packages

Zu guter Letzt müssen die neuen Dateien in der %files-Sektion eingetragen werden und die Shared MIME-Datenbank muss in den %post- und %postun-Skripten aktualisiert werden. Siehe auch Kapitel 10.1.3, "Shared MIME Info".

10.2. Kernel-Module

Detaillierte Informationen zum Kernel finden Sie unter http://www.suse.com/~agruen/KMPM/.

10.3. Perl-Module

Dieser Abschnitt beschreibt, wie Perl-Module unter SUSE paketiert werden. Dabei gelten die folgenden Regeln:

• Jedes Perl-Modul sollte in einem eigenen Paket sein.
• Der Paketname sollte perl-XXX sein, wobei XXX der Originalname des Quellcodearchivs ist. Siehe auch Kapitel 1.5, "Name Tag".
• Die RPM-Gruppe sollte Development/Libraries/Perl sein.
• Das Paket sollte die selbe Perl-Version erfordern, die zum Bau benutzt wurde. Das Makro %perl_version hilft ihnen dabei.

Abhängigkeiten von Perl-Modulen werden nicht automatisch erkannt. Das heißt, dass die Pakete die notwendigen Perl-Module im Requires Tag angeben müssen. Dies trifft ebenso auf die Abhängigkeit zwischen Perl-Modulen zu.

Das Paket perl und notwendige Perl-Module sollten im BuildRequires Tag angegeben werden.

Dieses Beispiel einer typischen spec-Dateieinleitung entstammt dem Paket perl-Inline-CPR:

# norootforbuild
 # usedforbuild    ... perl perl-Inline perl-Parse-RecDescent ...
 
 
 Name:         perl-Inline-CPR
 License:      Artistic License
 Group:        Development/Libraries/Perl
 Version:      0.12
 Release:      151
 Autoreqprov:  on
 Requires:     perl = %{perl_version}
 Requires:     perl-Inline
 Summary:      Write Perl subroutines in C
 URL:          http://cpan.org/modules/by-module/Inline
 Source:       Inline-CPR-%{version}.tar.bz2
 Patch:        Inline-CPR-%{version}.diff
 BuildRoot:    %{_tmppath}/%{name}-%{version}-build
 
 %description
 This module allows you to program C in perl. See also perl-Inline.
 
 
 Authors:
 --------
     Brian Ingerson <INGY@cpan.org>

Im obigen Beispiel sehen Sie, dass zwei andere Perl-Module zum Bauen und zur Laufzeit benötigt werden. Sie werden im BuildRequires Tag aufgeführt und das Paket perl-Inline ist zusätzlich Requires Tag eingetragen. Das zweite Paket perl-Parse-RecDescent muss nicht im Requires Tag angegeben werden, da es bereits von perl-Inline vorausgesetzt wird.

Die meisten Perl-Module lassen sich auf die gewohnte Art und Weise installieren. Zusätzlich sind noch die Makros %perl_make_install, %perl_process_packlist, %perl_vendorarch und %perl_vendorlib verfügbar. Diese machen es extrem einfach, ein Paket zu erstellen. Dieser Ansatz wird auch im Paket perl-Inline-CPR aus dem obigen Beispiel verfolgt. Es folgt der Rest der zugehörigen spec-Datei:

%prep
%setup -n Inline-CPR-%{version}
%patch

%build
perl Makefile.PL
make
make test

%install
%perl_make_install
%perl_process_packlist

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-, root, root)
%doc Changes README MANIFEST
%{perl_vendorlib}/Inline/CPR*
%{perl_vendorarch}/auto/Inline/CPR
/var/adm/perl-modules/%{name}

Im obigen Beispiel können Sie sehen, wie das Makro %perl_process_packlist verwendet wird. Es entfernt $RPM_BUILD_ROOT von einigen Dateien und erlaubt es, die Datei %perl_archlib/perllocal.pod als /var/adm/perl-modules/%{name} zu packen. Weitere Details dazu finden Sie in Kapitel 3.15, "%perl_process_packlist".

Nach der Installation des Pakets sollte SuSEconfig --module perl aufgerufen werden. Dies aktualisiert die %perl_archlib/perllocal.pod mit den Informationen die in /var/adm/perl-modules gespeichert sind. Es wird nicht aus dem %post-Skript heraus aufgerufen, da es endlos dauern würde, wenn mehrere Pakete auf einmal installiert würden und jedes davon dieses Skript unabhängig voneinander aufrufen würde.

Falls ein Modul einen in C geschriebenen Teil mitbringt können die $RPM_OPT_FLAGS folgendermaßen übergeben werden. Das Beispiel entstammt dem Paket perl-Bit-Vector:

%build
perl Makefile.PL OPTIMIZE="$RPM_OPT_FLAGS -Wall"
make
make test

10.4. Python Modules

Dieser Abschnitt beschreibt, wie Python-Module unter openSUSE paketiert werden. Dabei gelten die folgenden Regeln:

• Jedes Python-Modul sollte in einem separaten Paket unterkommen.
• Der Paketname sollte python-XXX sein. Sie auch Kapitel 1.5, "Name Tag".
• Die RPM-Gruppe sollte Development/Libraries/Python sein.
• Das Paket sollte Python in der selben Hauptversion erfordern, wie sie für den Bau verwendet wurde. Dies beugt Problemen beim Aktualisieren von Python vor. Für diesen Zweck existiert das Makro %py_requires. Im unteren Beispiel sehen Sie, wie es funktioniert.

Die Pakete python und python-devel werden normalerweise für den Bau benötigt. Sie müssen dafür im Tag BuildRequires angegeben werden.

Dieses Beispiel einer typischen spec-Dateieinleitung entstammt dem Paket python-numeric:

 # norootforbuild
 
 Name:           python-numeric
 BuildRequires:  python-devel
 Summary:        A Numerical Extension to Python
 Version:        24.2
 Release:        5
 %define tarname Numeric
 Source0:        %{tarname}-%{version}.tar.bz2
 License:        BSD, Python
 Group:          Development/Libraries/Python
 URL:            http://sourceforge.net/projects/numpy
 Autoreqprov:    on
 BuildRoot:      %{_tmppath}/%{name}-%{version}-build
 
 %py_requires
 
 %description
 Numerical Python adds a fast and compact multi-dimensional array
 language facility to Python.
 
 Authors:
 --------
     numpy-developers@lists.sourceforge.net

Die meisten Python-Module nutzen mittlerweile distutils, so dass es extrem einfach ist, sie zu paketieren. Diese Fähigkeit wird unter http://www.python.org/sigs/distutils-sig/ dokumentiert. Dies wird auch im Paket python-numeric aus dem obigen Beispiel genutzt. Es folgt der Rest der zugehörigen spec-Datei:

%prep
%setup -n Numeric-%{version}
%patch

%build
export CFLAGS="$RPM_OPT_FLAGS"
python setup.py build

%install
python setup.py install --root=$RPM_BUILD_ROOT \
                        --prefix=%{_prefix} \
       --record-rpm=INSTALLED_FILES

%clean
rm -rf $RPM_BUILD_ROOT

%files -f INSTALLED_FILES
%defattr(-,root,root)
%doc README changes.txt Demo

Im obigen Beispiel können Sie sehen, wie die Variable $RPM_OPT_FLAGS in der Regel zum Bau von Binärdateien genutzt wird. Bei Installationskommando können Sie auch sehen, dass die Option --record-rpm genutzt werden kann, um eine Dateiliste zu erstellen, die dann in der %files-Sektion weiterverwendet werden kann. Diese Fähigkeit existiert zur Zeit nur in SUSE-Python-Paketen. Ein Patch für das Ursprungsprojekt erwartet noch seine Überprüfung.

Falls ein Paket eine standardungemäße Baumethode verwendet, können die speziellen RPM-Makros %py_ver, %py_incdir, %py_libdir und %py_sitedir genutzt werden, um den Ort der Pathon-Verzeichnisse zu erhalten.

Dieses Beispiel entstammt dem Paket python-fcgi:

Source0:      http://alldunn.com/python/fcgi.py
[...]

%prep

%build

%install
install -m755 -d $RPM_BUILD_ROOT/%{py_sitedir}
install -m644 %{S:0} $RPM_BUILD_ROOT/%{py_sitedir}
python%{py_ver} %{py_libdir}/compileall.py -d %{py_site}/ \
   $RPM_BUILD_ROOT/%{py_sitedir}

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root)
%{py_sitedir}/fcgi.py*

10.4. KDE 3.x-Pakete

Für den beginnenden Paketbauer hält das KDE-Paketbaukochbuch eine Schritt-für-Schritt-Paketbauanleitung für KDE-Anwendungen bereit.

Eine typische spec-Datei für ein KDE-Paket sieht in etwa so aus:

# norootforbuild


 Name:           knutclient
 Version:        0.9.3
 Release:        3
 License:        GPLv2
 URL:            http://www.foo.org
 BuildRoot:      %{_tmppath}/%{name}-%{version}-build
 BuildRequires:  kdelibs3-devel update-desktop-files
 Source:         %{name}-%{version}.tar.bz2
 Requires:       nut
 Group:          Hardware/UPS
 Summary:        NUT GUI Interface

 %description
 Knutclient is a GUI interface for UPS system NUT
 

 Authors:
 --------
     john.doe@foo.org

Der einzige KDE-spezifische Teil im Dateikopf ist das kdelibs3-devel in BuildRequires. Dieses Paket wird zum Bau aller KDE-Pakete benötigt. Es gibt einen Haufen von Ausnahmen (bspw. kicker-Erweiterungen), die bestimmtere Entwicklungspakete benötigen, bspw. kdebase3-devel oder kdepim3-devel.

 %prep
. /etc/opt/kde3/common_options
 %setup -n %{name}-%{version} -q
update_admin
 

Die Datei /etc/opt/kde3/common_options setzt alle Umgebungsvariablen und -Flags auf die korrekten Werte, die zur Kompilierung von KDE-Anwendungen nötig sind. Definieren Sie also nicht jedes Mal $KDEDIR, $QTDIR usw. neu, wie sie es beim kompilieren von KDE-Anwendungen von Hand machen.

update_admin ist ein Shell-Makro, dass das admin-Verzeichnis des Pakets auf die letzte Version des kdelibs-devel-Pakets aktualisiert. Dies initialisiert das (autotools) Build System und wird (abhängig von der Distribution, für die gebaut wird) zu unsermake als Bauwerkzeug wechseln.

Falls ein Paket, dass Sie zu bauen versuchen, nicht mit unsermake funktioniert, können Sie den Parameter --no-unsermake parameter an update_admin übergeben, um einen regulären Bau mit automake zu erzwingen.

 %build
 . /etc/opt/kde3/common_options
 ./configure $configkde
 do_make %{?jobs:-j%jobs}
 

Sie müssen common_options erneut einbinden, dieses mal, um die korrekten $RPM_OPT_FLAGS für die Bauphase zu erhalten. Die Variable $configkde enthält alle richtigen Flags für einen allgemeinen Aufruf von ./configure. Es fügt bei neueren Distributionen außerdem --enable-final hinzu. Dies beschleunigt die Kompilierung durch das Verbinden aller .cpp-Dateien zu einer Datei, die dann als ganzes kompiliert wird. Falls ihr Paket nicht mit --enable-final funktioniert und es nicht möglich ist, dies zu beheben, können Sie nach $configkde --disable-final einfügen, um den Standard wiederherzustellen.

'do_make' wird entweder make oder unsermake aufrufen, abhängig vom Weg, auf dem update_admin aufgerufen wurde.

 %install
 . /etc/opt/kde3/common_options
 do_make DESTDIR=$RPM_BUILD_ROOT $INSTALL_TARGET
 %suse_update_desktop_file %name System Monitor
 %find_lang %name
 kde_post_install
 

Das einzige spezifische Makro ist hier kde_post_install. Es erledigt eine Reihe uninteressanter Dinge, wie das Markieren installierter .desktop-Dateien zur Übersetzung oder zur Verschiebung von crystalsvg-Symbolen nach hicolor, so dass sie auch von nicht-KDE-Arbeitsflächen verwendet werden können. Es sollte immer die letzte nicht Standardzeile in ihrer %install-Sektion sein.

 %clean
 rm -rf "$RPM_BUILD_ROOT"
 

Standard %clean-Sektion.

 %files -f %name.lang
 %defattr(-,root,root)
 %doc README AUTHORS ChangeLog COPYING INSTALL
 /opt/kde3/bin/*
 /opt/kde3/share/apps/knutclient
 /opt/kde3/share/icons/??color
 /opt/kde3/share/applnk/Utilities/knutclient.desktop
 /opt/kde3/share/locale/*/LC_MESSAGES/*.mo
 /opt/kde3/share/doc/HTML/??/knutclient/*
 

Dies ist eine Standard-%files-Sektion, die die typische Struktur der Unterstützungsdateien einer KDE-Anwendung wiedergibt.