openSUSE:Paketbauvereinbarungen zu RPM-Makros

Paketbau

Paketbau Richtlinien - Richtlinien zur Bezeichnung von Paketen - Richtlinien für Spezifikationsdateien - Richtlinien für Patches - Sicherheitsrichtlinien - Richtlinien für Paketgruppen - Paketbau Prüfungen - Kategorien für Desktopmenüs - RPM Makros - Init-Skripte - kleine Skript-Schnipsel - Paketbau Perl - Paketbau-Richtlinie für mehrfach benutzte Bibliotheken - Paketabhängigkeiten - Paketbau von Python-Software - Paketbau Richtlinien für mehrere Versionen

Dieser Abschnitt beschreibt vordefinierte RPM-Makros, die in den Paketen von openSUSE verwendet werden. Einige von ihnen sind typische RPM-Makros. Einige sind SUSE-spezifische Makros. Für andere vorhandene typische Makros sollte andere Dokumentationen konsultiert werden, so wie Maximum RPM oder Makro Syntax. Die auf Java bezogenen Makros werden auf der Seite en:openSUSE:Packaging_Java beschrieben. Wenn Sie moderne RPM-Makros programmieren wollen, hat RPM eine eingebaute Unterstützung für die Programmiersprache Lua. Sie können alle vordefinierten Makros in den Dateien /usr/lib/rpm/macros und suse_macros mit einigen Erklärungen finden. Zusätzliche Paket-spezifische Makros werden von Dateien in /etc/rpm hinzugefügt. Wenn Sie das Makro %dump in Ihrer Spezifikationsdatei unterbringen und die Spezifikationsdatei rpmbuild -bp verwenden, dann wird das für alle Makros, die in Ihrem System zur Verfügung stehen, eine Entsorgung verursachen.

RPM-Makros

Syntax

Warnung!Die Gültigkeit der Behauptungen in diesem Unterabschnitt sind unsicher. Momentan ist es möglich, Optionen mit Parametern zu vermischen, was gewöhnlich gemacht wird. Zum Beispiel: %kernel_module_package -p preamble -x xen xenpae.

Ein wichtiger Unterschied zwischen RPM-Makros und normalen Linux-Kommandos ist, wie die Optionen und Parameter definiert sind. RPM liefert nur eine einfache Unterstützung für Verarbeitungsoptionen. Eine Begrenzung ist, dass alle Optionen müssen vor Parametern definiert werden. Und es ist nicht möglich, einfach Paare zu verwenden, die aus einer Option und einem bezogenen Wert erzeugt werden. Zum Beispiel verwendet das Linux-Kommando top die folgende Zusammenfassung:

top [-bcisS] [-d delay] [-n iterations] [-p pid] [, pid ...]

Die verwendeten Paare -d delay, -n iterations, -p pid und alle Parameter sind optional. Dei Option vor einem Parameter definiert, welcher Parameter auf der Kommandozeile wirklich verwendet wird. Das macht es möglich, folgendes aufzurufen:

Beispiel 1: top -n 20 -p 10345

Beispiel 2: top -d 1 -p 10345

und das Kommando weiss, dass 20 eine Zahl der Iterationen ist, 1 ist eine Verzögerung und 10345 eine PID.

Aufgrund der Begrenzung in RPM würde die Kurzfassung eines verbundenen RPM-Makro wie folgt aussehen:

%top [-bcisSdnp] [delay] [iterations] [pid] [,pid ...]

Alle Optionen müssen vor den Parametern definiert werden und die Optionen wiederum definieren, welcher Parameter wirklich verwendet wird. Das bedeutet, dass die bezogenen Aufrufe der potentiellen RPM-Makros der obigen Beispiele wie folgt aussehen würden:

Beispiel 1: %top -n -p 5 10345

Beispiel 2: %top -d -p 1 460

%_docdir

Dieses Makro wird ersetzt durch das Standardverzeichnis für Dokumentation /usr/share/doc/packages. Es könnte durch die Markierung Docdir neu definiert werden. Gewöhnlich wird es benötigt, um eine Dokumentation im Abschnitt %install zu installieren, wenn es nicht ausreicht, es in %files mit der Markierung %doc zu machen. Weiterhin muß die Markierung %doc nicht zusammen mit %_docdir im Abschnitt %files verwendet werden. Es wird für dieses Verzeichnis automatisch gemacht.

Dieses Beispiel ist dem Paket aeolus entnommen:

%install
[...]
mkdir -p "%buildroot/%_docdir/%name"
cp .aeolusrc "%buildroot/%_docdir/%name/aeolusrc"
cp -R stops-* "%buildroot/%_docdir/%name"
[...]

%files
[...]
%_docdir/%name

%_infodir

Dieses Makro wird durch das Standardverzeichnis für Info-Seiten /usr/share/info ersetzt. Es wird oft mit `./configure --infodir=%_infodir`, mit dem Makro %install_info und in der Dateiliste verwendet. Wie bei %_docdir muss die Markierung %doc zusammen %_infodir im Abschnitt %files verwendet werden. Es wird automatisch für dieses Verzeichnis durchgeführt.

%_lib

Dieses Makro ersetzt entweder lib oder lib64, je nach dem. Die zweite Variante erscheint auf 64-bit Architekturen mit paralleler Unterstützung von 64-bit und 32-bit Programmen (biarch systems). Auf derartigen Systemen müssen zwei Varianten der gleichen Bibliothek koexistieren. Darum sind die 64-bit-Bibliotheken im Verzeichnis lib64 und die 32-bit-Bibliotheken im traditionellen Verzeichnis lib installiert.

%_lib selbst wird verwendet, wenn das Makro %_libdir nicht ausreicht, zum Beispiel wenn Bibliotheken in /usr/X11R6/%_lib gehen sollen. Es wird oft mit `./configure -–libdir=/usr/X11R6/%_lib` und in der Dateiliste verwendet.

%_libdir

Dieses Makro wird durch %_prefix/%_lib ersetzt. Es hat die gleiche Funktion wie %_lib und wird öfter als dieses verwendet, da die Bibliotheken gewöhnlich unter /usr/lib(64) installiert werden. Es wird mit `./configure --libdir=%_libdir` und in der Dateiliste verwendet.

%_mandir

Dieses Makro wird durch das Standardverzeichnis für Anleitungsseiten /usr/share/man ersetzt. Es wird oft verwendet mit `./configure --mandir=%_mandir` und im Abschnitt %files, so zum Beispiel in

%files
%_mandir/*/*

Wie mit %_docdir, die Markierung %doc muss nicht zusammen mit %_mandir im Abschnitt %files verwendet werden. Es wird für dieses Verzeichnis automatisch ausgeführt.

%desktop_database_post / %desktop_database_postun

Diese Makros müssen für jede Anwendung aufgerufen werden, die eine Desktopdatei, die ein Steuerungsprogramm vom Typ MIME enthält, installiert. Das wird den System-MIME-Catch, durch Aufrufen der update-desktop-database, aktualisieren.

Diese Makros stehen ab 11.4 zur Verfügung!

%define

Dieses Makro wird verwendet, um massgeschneiderte Makros innerhalb einer speziellen Spezifikationsdatei zu definieren. Verwenden Sie es als einen Platzhalter für wiederkehrende Wörter, wie eine kundenspezifische Bezeichnung für das Paket

 %define custom_version 12.6_64
 ..
 %setup -q -n %{name}-%{custom_version}

%fdupes

Dieses Makro wird verwendet, um doppelte Dateien in Ihrem $RPM_BUILD_ROOT hart oder weich zu verlinken. Das wird verwendet, um den Installationsumfang Ihres Pakete zu reduzieren und in manchen Fällen ebenso die die Größe des RPM-Paketes selbst. Bitte sind Sie sorgfältig, so dass diese doppelten Dateien nicht in unterschiedlichen Unterpaketen landen. Wir haben noch nicht ausprobiert, was RPM im Fall eines harten Links macht. Wenn Sie Zweifel hegen, können Sie  %fdupes -s verwenden, was Symlinks erzeugen wird, die leichter für RPM zu greifen sind. Und rpmlint wird einen Fehler "dangling symlink" ausgeben, wenn die Datei und der Link in unterschiedlichen Paketen landen.

Sie können ebenso diese Links, wie nachfolgend, kombinieren:

 ..
 BuildRequires:  fdupes 
 ..
 %install
 ..
 # erzeuge Symlinks für man pages
 %fdupes -s $RPM_BUILD_ROOT/%_mandir
 # erzeuge Hardlinks für den Rest
 %fdupes

Dies ist eine RPMLint Überprüfung, die einen Fehler für das Paket ausgeben wird, wenn es einen beträchlichen Umfang an Platz verschwendet. Wenn Sie nicht fdupes beim Bau anfordern, werden Sie einen Fehler "no job control" erhalten.

%fillup_and_insserv

Dieses Makro kann verwendet werden, um die Dateien sysconfig aufzufüllen und mit insserv installierte Init-Skripte zu aktivieren.

Syntax:

%fillup_and_insserv [-finyY] [sysconfig_filename] [init_script_name] ...

Das Makro %fillup_and_insserv kombiniert zwei Funktionen in einem Kommando. Es wird verwendet, um Config-Dateien einzusetzen (aufzufüllen) in /etc/sysconfig und um Sevice in Laufebenen zu aktivieren. Der Auffüllteil verwendet eine Vorlage, die unter /var/adm/fillup-templates/sysconfig_filename.%name gespeichert ist.

Das Makro wird im Abschnitt %post der Pakete verwendet, die ein Init-Skript installieren und sie per Standard aktivieren wollen. Mehr Informationen finden Sie unter “Installation”. Vergessen Sie nicht, die verwendeten Dienstprogramme in PreReq zu erwähnen. %insserv_prereq und %fillup_prereq unterstützen diesen Zweck.

(Da insserv/fillup nur in %post aufgerufen wird, sollte Requires(post) nicht geeigneter sein als PreReq?)

Optionen:

• -f überspringt den Auffüllteil.
• -i überspringt den Teil insserv.
• -n definiert, dass der Parameter sysconfig_filename verwendet wird (siehe unten).
• -y verursacht die Aktivierung des Init-Skripts per Standard, wenn das Paket zum ersten Mal installiert ist (nicht während der Aktualisierung). Es wird ignoriert, wenn X-UnitedLinux-Default-Enabled im Init-Skript spezifiziert ist.
• -Y aktiviert den Service nachdrücklich. Das bedeutet, dass der Service immer aktiviert ist, unabhängig von den Einstellungen vor einer Aktualisierung.

Parameter:

• sysconfig_filename erzeugt ein Paar mit der Option -n und definiert die Dateibezeichnung, wo die Konfiguration aufgefüllt wird, /etc/sysconfig/sysconfig_filename. Zusätzlich definiert es eine Bezeichnung der Datei mit Vorlagen. Das Makro sucht nach zwei möglichen Vorlagedateien. Es bevorzugt /var/adm/fillup-templates/sysconfig.sysconfig_filename.%name, wenn es zur Verfügung steht. Andernfalls sucht es nach /var/adm/fillup-templates/sysconfig.sysconfig_filename. Die längere Variante muss verwendet werden, wenn mehrere Pakete in die gleiche Config-Datei schreiben. Per Standard (das ist, wenn die Option -n verwendet wird), ist die Vorlage /var/adm/fillup-templates/sysconfig.%name und die Ziel-Konfigurations-Datei /etc/sysconfig/%name.
• init_script_name definiert den Namen des Init-Skripts, dass von `insserv` verarbeitet wird. Es muss definiert werden, wenn die Option -i nicht verwendet wird. Weitere Init-Skripte-Bezeichnungen können definiert werden (siehe das Beispiel unten).

Beispiel vom Paket mailman:

PreReq: %insserv_prereq  %fillup_prereq ...

%post
%{fillup_and_insserv mailman}

Es füllt die Konfigurationsdatei /etc/sysconfig/mailman mit der Vorlage /var/adm/fillup-templates/sysconfig.mailman.

Beispiel vom Paket hwinfo:

PreReq: %insserv_prereq

%post
%{fillup_and_insserv -f -y hwscan}

Es startet `insserv` auf /etc/init.d/hwscan und aktiviert den Service standardmäßig. Beachten Sie, dass nur der insserv Teil in PreReq ist, weil der fillup weg gelassen wird, da die Option -f verwendet wurde.

Beispiel vom Paket openssh:

%{fillup_and_insserv -n -y ssh sshd}

Es füllt die Konfigurationsdatei /etc/sysconfig/ssh. Die Vorlage wird entweder von /var/adm/fillup-templates/sysconfig.ssh.openssh oder von /var/adm/fillup-templates/sysconfig.ssh genommen. Die erste Version wird bevorzugt. Sie startet`insserv` auf /etc/init.d/sshd und aktiviert den Service standardmäßig während einer neuen Installation.

Beispiel vom Paket openldap2:

%{fillup_and_insserv -n openldap ldap slurpd}

Es füllt die Konfigurationsdatei /etc/sysconfig/openldap. Die Vorlage wird entweder von /var/adm/fillup-templates/sysconfig.openldap.openldap2 oder von /var/adm/fillup-templates/sysconfig.openldap genommen. Das vorhergehende wird bevorzugt.

%fillup_only

Dieses Makro kann verwendet werden, um die Datei sysconfig zu füllen.

Syntax:

%fillup_only [-adns] [sysconfig_filename] [suffix] [sysconfig_subdir]

Das Makro %fillup_only wird verwendet, um die Variablen aus einer Vorlage /var/adm/fillup-templates/sysconfig.sysconfig_Dateiname[-suffix] in eine config-Datei /etc/sysconfig/sysconfig_Dateiname einzusetzen. Die Basisfunktion ist ähnlich zu %fillup_and_insserv -i, aber sie erlaubt es, die config-Dateien in Unterverzeichnisse von /etc/sysconfig zu bearbeiten.

Das Makro wird typischer Weise im Abschnitt %post genutzt. Vergessen Sie nicht, die Dienstprogramme, die der Markierung PreReq verwendet werden, zu erwähnen. Das Makro %fillup_prereq ist für diesen Zweck beabsichtigt.

Optionen:

• -a verwendet die Paketbezeichnung als Suffix der sysconfig-Vorlage-Dateibezeichnung.
• -d definiert, dass der Parameter sysconf_subdir verwendet wird (siehe unten).
• -n definiert, dass der Parameter sysconfig_filename verwendet wird (siehe unten).
• -s definiert, dass der Parameter suffix verwendet wird (siehe unten).

Parameter:

• sysconfig_filename erzeugt ein Paar mit der -n option und definiert die Bezeichnung der sysconfig Datei und eine Bezeichnung der datei mit Vorlagen. Per Standard (das ist, wenn die Option -n nicht verwendet wird), wird die Paketbezeichnung stattdessen verwendet. Soe wird die Vorlage /var/adm/fillup-templates/sysconfig.%name in /etc/sysconfig/%name aufgefüllt.
• sysconfig_template_filename_suffix erzeugt ein Paar mit der Option -s und definiert einen Suffix der Dateibezeichnung mit Vorlagen.
• sysconfig_subdir erzeugt ein Paar mit der Option -d und definiert ein Unterverzeichnis von /etc/sysconfig, wo sich die Datei synconfig befindet.

Beispiel vom Paket tetex:

PreReq: %fillup_prereq

%post
%fillup_only

Es füllt die Konfigurationsdatei /etc/sysconfig/tetex von der Vorlage /var/adm/fillup-templates/sysconfig.tetex auf.

Beispiel vom Paket man:

%{fillup_only -an cron}

Es füllt die Konfigurationsdatei /etc/sysconfig/cron von der Vorlage /var/adm/fillup-templates/sysconfig.cron-man auf.

Beispiel vom Paket dhcp:

%{fillup_only -ans syslog dhcpd}

Es füllt die Konfigurationsdatei /etc/sysconfig/syslog</t> von der Vorlage <tt>/var/adm/fillup-templates/sysconfig.syslog-dhcpd auf.

Beispiel vom Paket samba:

%fillup_only -nsd dhcp samba-client network

Es füllt die Konfigurationsdatei /etc/sysconfig/network/dhcp von der Vorlage /var/adm/fillup-templates/sysconfig.dhcp-samba-client auf.

%find_lang

Dieses Makro hilft, lokal-abhängige Dateien mit der entsprechenden Markierung %lang in der Dateiliste zu finden.

Syntax

%find_lang options name [filelist]

Das Makro %find_lang durchsucht die Verzeichnisse /usr/share/locale und locale/*/LC_MESSAGES nach name.mo Dateien. Es durchsucht ebenso die Verzeichnisse gnome/help/name und kde*/share/doc/HTML/*/name nach Lokalisierungsdokumentationen. Dann erzeugt es die Datei filelist, wo die Dateien mit der entsprechenden Markierung %lang(locale) und %doc gekennzeichnet werden. Solch eine Dateiliste kann zur Markierung %files über die Option -f weiter geleitet werden. Siehe das Beispiel unten.

Es wird empfohlen, dieses Makro nur zu verwenden, wenn die Markierung BuildRoot definiert ist, andernfalls wird das ganze System durchsucht.

Optionen

--without-gnome

findet die GNOME-Hilfe-Dateien nicht.

--without-kde

findet die KDE-Hilfe-Dateien nicht.

--with-qt

findet Qt-Übersetzungs-Dateien.

--with-man

findet die lokalisierten Man-pages.

--all-name

alle Paket/Domain-Namen zuordnen.

--without-mo

findet keine lokalen Dateien.

Parameter

name

definiert die Bezeichnung von .mo -Dateien und den Namen der Unterverzeichnisse, in denen die lokalisierte Dokumentation von GNOME und KDE gespeichert ist. Sie wird auch für filelist verwendet, in der die erzeugte Dateiliste gespeichert wird, wenn der Parameter filelist nicht vergeben ist.

filelist

definiert die Bezeichnung der Dateiliste, in der die erzeugte Liste von Dateien gespeichert wird. name.lang wird verwendet, wenn nichts anderes definiert ist.

Beispiel vom Paket pan:

%install
make -i DESTDIR="%buildroot" install
%find_lang %name                # erzeugt eine spezielle Dateiliste

%files -f %name.lang            # verwendet die spezielle Dateiliste
%defattr(-,root,root)           # listet die anderen Dateien
%doc README ChangeLog AUTHORS TODO COPYING CREDITS
%attr(755,root,root) %prefix/bin/pan
[…]

%icon_theme_cache_post / %icon_theme_cache_postun

Dieses Makro wird verwendet, um den Icon-Motive-Zwischenspeicher für Pakete zu aktualisieren, die Icons mit hicolor der anderen Icon-Themen installieren. Es ist vorgesehen, es in den Abschnitten %post und %postun aufzurufen und ein Optionsargument zu nehmen, das die Bezeichnung des aktualisierten Icons-Themas hat, wobei hicolor der Standard ist.

Dieses Makro ist nur ab 11.4 verfügbar!

FIXME: Welches tag wird für Requires(post/postun) benötigt?

%insserv_cleanup

Dieses Makro wird verwendet, um `insserv` zu starten, nachdem ein Paket gelöscht wurde. Jedes Paket, das ein Init-Skript unterstützt, sollte dieses Makro im Abschnitt %postun aufrufen.

Beispiel vom Paket openldap2:

%postun
%restart_on_update ldap slurpd
%insserv_cleanup

%insserv_force_if_yast

Dieses makro ist ein direkter Aufruf von `insserv`, wenn ein Paket nicht von YaST installiert wird. Wenn YaST verwendet wird, ruft es stattdessen `insserv -f` auf. Der hilft, Fehler bei Paketinstallationen "außer-der-Reihe" zu vermeiden .

Dieses Makro wird im Skript %post von Paketen verwendet, die ein Init-Skript installieren und es per Standard aktivieren wollen. Es wird ebenso verwendet, wenn das Init-Skript vor SL 8.0 existierte, als die Variable START verwendet wurde. Siehe openSUSE:Packaging_init_scripts#Installation, für mehr Details. Vergessen Sie nicht die Verwendung der Dienstprogramme in der Markierung PreReq zu erwähnen. Es gibt die Makros %insserv_prereq und %fillup_prereq für diesen Zweck.

Beispiel vom Paket glibc und Unterpaket nscd:

%package -n nscd
PreReq: %insserv_prereq

%post -n nscd
%{insserv_force_if_yast nscd}

%install_info

Dieses Makro aktualisiert die Einträge dir für die Info-Dateien.

Syntax:

%install_info install_info_options

Das Makro %install_info startet `bin/install-info` mit einigen zusätzlichen Tests. Es akzeptiert jede Option vom Dienstprogramm install-info. Siehe `man install-info` bezüglich weiterer Details.

Jedes Paket, das Info-Seiten unterstützt, sollte dieses Makro im Abschnitt %post aufrufen. Vergessen Sie nicht, alle verwendeten Dienstprogramme in der Markierung PreReq zu erwähnen. Das Makro %install_info_prereq dient diesem Zweck.

Beispiele:

Beispiel vom Paket zsh:

PreReq: %install_info_prereq

%post
%install_info --info-dir=%_infodir %_infodir/%name.info.gz

Beispiel vom Paket rplay (ein Paket mit mehreren Info-Seiten):

PreReq: %install_info_prereq

%post
%install_info --info-dir=%_infodir %_infodir/%name.info.gz
%install_info --info-dir=%_infodir %_infodir/RPLAY.info.gz
%install_info --info-dir=%_infodir %_infodir/RPTP.info.gz
%install_info --info-dir=%_infodir %_infodir/librplay.info.gz

%install_info_delete

Dieses Makro löscht die Einträge für Info-Dateien.

Syntax:

%install_info_delete install_info_options

Das Makro %install_info_delete ist eine Ergänzung zum Makro %install_info. Es startet sbin/install-info --quiet –delete mit einigen zusätzlichen Tests. Es akzeptiert alle Optionen vom Dienstprogramm install-info. Siehe man install-info bezüglich weiterer Details.

Jedes Paket, das Info-Seiten unterstützt, sollte dieses Makro im Skript %postun aufrufen. Vergessen Sie nicht, alle Dienstprogramme zu erwähnen, die in der Markierung PreReq verwendet werden. Das Makro %install_info_prereq ist für diesen Zweck vorgesehen.

Beispiele:

• Dieses Beispiel ist dem Paket zsh entnommen (zeigt ebenso die verbundene Markierung PreReq):

PreReq: %install_info_prereq
[...]
%postun
%install_info_delete --info-dir=%_infodir %_infodir/%name.info.gz

• Dieses Beispiel ist dem Paket rplay entnommen (ein Paket mit mehreren Info-Seiten). Das Beispiel zeigt auch die verbundene Markierung PreReq):

PreReq: %install_info_prereq
[...]
%postun
for infoname in %name RPLAY RPTP librplay; do
%install_info_delete --info-dir=%_infodir %_infodir/$infoname.info.gz
done

%perl_archlib

Dieses Makro wird durch den Pfad, unter dem Architektur-spezifische Teile von Perl installiert werden, ersetzt. Zum Beispiel /usr/lib/perl5/5.8.5/i586-linux-thread-multi.

Es wird normaler Weise durch das Paket perl selbst und vom Makro %perl_process_packlist verwendet. Siehe unten.

%perl_gen_filelist

Es erzeugt eine mit rpmlint zufriedene Dateiliste Ihrer installierten Dateien.

In den meisten Fällen müssen Sie nur den Teil  %doc prüfen. Manchmal gibt ein "Changes" oder "ChangeLog"....

Sie müssen folgende Teile innerhalb Ihrer Spezifikationsdatei definieren.

Beispiel:

BuildRequires:  perl-macros

%install
%perl_make_install
%perl_process_packlist
%perl_gen_filelist

%files -f %{name}.files
%defattr(-,root,root)
%doc Changes README

Und hier ein Beispiel für eine erzeugte Dateiliste:

%dir /usr/lib/perl5/vendor_perl/5.8.8/Algorithm
/usr/lib/perl5/vendor_perl/5.8.8/Algorithm/DiffOld.pm
/usr/lib/perl5/vendor_perl/5.8.8/Algorithm/diff.pl
/usr/lib/perl5/vendor_perl/5.8.8/Algorithm/Diff.pm
/usr/lib/perl5/vendor_perl/5.8.8/Algorithm/diffnew.pl
/usr/lib/perl5/vendor_perl/5.8.8/Algorithm/cdiff.pl
/usr/lib/perl5/vendor_perl/5.8.8/Algorithm/htmldiff.pl
%dir /usr/lib/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/Algorithm
%dir /usr/lib/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/Algorithm/Diff
/usr/lib/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/Algorithm/Diff/.packlist
/usr/share/man/man?/*
/var/adm/perl-modules/perl-Algorithm-Diff

%perl_make_install

Dieses Beispiel führt den Aufruf von make install für verschiedene Produkte richtig aus. Vor SL 9.0 war der normale Weg es aufzurufen:

make PREFIX=$RPM_BUILD_ROOT/%_prefix \
INSTALLMAN1DIR=$RPM_BUILD_ROOT/%_mandir/man1 \
INSTALLMAN3DIR=$RPM_BUILD_ROOT/%_mandir/man3 \
install

Für 9.0 und nachfolgende Versionen:

make DESTDIR=$RPM_BUILD_ROOT install_vendor

Mit dem Makro %perl_make_install wird es entsprechend der Version korrekt ausgeführt.

Dieses Beispiel stammt von dem Paket perl-URI:

%install
%perl_make_install

%perl_process_packlist

Dieses Makro bereitet einige Dateien, die mit den Perl-Modulen verbunden sind, für das endgültige Paket vor. Es führt die folgenden Aktionen aus:

Jedes Paket, das ein Perl-Modul enthält, sollte dieses Makro im Abschnitt %install aufrufen.

Für 0%{?suse_version} > 1130

• Sucht nach installierten .packlist Dateien und löscht sie aus $RPM_BUILD_ROOT%perl_vendorarch/auto.
• Wenn %{_target_cpu} == noarch dann die leeren Verzeichnisse aus $RPM_BUILD_ROOT%perl_vendorarch/auto gelöscht sind, löscht die Datei $RPM_BUILD_ROOT%perl_archlib/perllocal.pod.

Dieses Beispiel ist dem Paket perl-HTML-Parser entnommen:

%install
%perl_make_install
%perl_process_packlist
%perl_gen_filelist

%files -f %{name}.files
%doc Changes mkhctype mkpfunc README TODO eg

%changelog

Für 0%{?suse_version} <= 1130

• Löscht $RPM_BUILD_ROOT von %perl_archlib/perllocal.pod und benennt die Datei zu einer Paket-spezifischen Datei um. Siehe unten nach mehr Details.
• Sucht nach installierten .packlist Dateien und löscht $RPM_BUILD_ROOT daraus.

Die Datei %perl_archlib/perllocal.pod muss umbenannt werden, weil sie Informationen über zusätzlich installierte Perl-Module enthält und offensichtlich nicht an dem gleichen Platz mit mehreren Paketen installiert werden kann. Darum wird sie umbenannt und ein spezielles SUSEconfig-Modul /sbin/conf.d/SuSEconfig.perl fügt diese Information zum System %perl_archlib/perllocal.pod, nachdem das Paket installiert ist.

Dieses Beispiel wurde dem Paket perl-URI entnommen:

%install
%perl_make_install
%perl_process_packlist

%files
[...]
/var/adm/perl-modules/%name

%perl_sitearch

Dieses Makro wird durch den Pfad ersetzt, wo Architektur-spezifische Teile von Perl-Modulen vom lokalen Administrator installiert werden (/usr/lib/perl5/site_perl/5.8.5/i586-linux-thread-multi). Die Pakete, die mit SUSE herausgegeben werden, verwenden den Pfad, der stattdessen von %perl_vendorarch definiert wird. Siehe unten.

%perl_sitelib

Dieses Makro wird ersetzt durch den Pfad, wo Architektur-spezifische Teile von Perl-Modulen vom lokalen Administrator installiert werden (/usr/lib/perl5/site_perl/5.8.5). Die Pakete, die mit SUSE heraus gegeben werden, verwenden den Pfad, der von %perl_vendorlib definiert wird. Siehe unten.

%perl_vendorarch

Dieses Makro wird ersetzt durch den Pfad, wo Architektur-spezifische Teile von Perl-Modulen von einem Linux Anbieter installiert werden (/usr/lib/perl5/vendor_perl/5.8.5/i586-linux-thread-multi). Das Makro wird typischer Weise in der Dateiliste verwendet. Dieses Beispiel kommt von dem Paket perl-URI:

%files
[...]
%perl_vendorarch/auto/URI

Dieser Pfad wurde seit SL 9.0 verwendet. Bis dahin wurden die Perl-Module unter /usr/lib/perl5/site_perl installiert, unter Verwendung des Makros %perl_sitearch. Das Verzeichnis site_perl ist nun für Module vorgesehen, die vom lokalen Administrator installiert werden. Siehe oben unter %perl_sitearch.

%perl_vendorlib

Dieses Makro ersetzt den Pfad, wo Architektur-spezifische Teile von Perl-Modulen von einem Linux-Anbieter installiert werden (/usr/lib/perl5/vendor_perl/5.8.5). Das Makro wird typischer Weise in der Dateiliste verwendet. Das Beispiel kommt vom Paket perl-URI:.

%files
[...]
%perl_vendorlib/URI.pm
%perl_vendorlib/URI

Dieser Pfad wurde seit SL 9.0 verwendet. Bis dahin wurden die Perl-Module unter /usr/lib/perl5/site_perl installiert, unter Verwendung des Makros %perl_sitearch. Das Verzeichnis site_perl ist nun für Module, die vom lokalen Administator installiert werden, vorgesehen. Siehe oben bei %perl_sitelib.

%perl_version

Dieses Makro wird ersetzt durch die Version von Perl, die zum Bau der Pakete verwendet wird, so wie 5.8.5. Es wird verwendet in einem Paket, das ein Perl-Modul unterstützt, um die Abhängigkeiten von Perl zu definieren.

Es wird typischer Weise wie folgt verwendet. Dieses Beispiel ist dem Paket perl-URI entnommen :

%{perl_requires}

und wurde auf diese Weise erweitert :

%perl_requires() \
%if 0%{?suse_version} > 0 && 0%{?suse_version} < 1700 \
Requires: perl = %{perl_version} \
%endif

%py_incdir

Dieses Makro wird ersetzt durch den Pfad, wo Python-Header-Dateien installiert werden, so wie /usr/include/python2.3. Siehe zum Beispiel “Python Module” unter openSUSE:Paketbau von Python-Software.

%py_libdir

Dieses Makro wird ersetzt durch den Pfad, unter dem Python-Module installiert sind, so wie /usr/lib/python2.3. Siehe zum Beispiel unter "Python-Module" openSUSE:Paketbau von Python-Software.

%py_requires

Dieses Makro wird ersetzt durch PreReq und die Markierungen BuildRequires. Das definiert die Abhängigkeit zur gleichen Python-Haupt-Version, wie sie während des Baus verwendet wird. Lesen Sie über “Python Module” in openSUSE:Paketbau von Python-Software.

%py_sitedir

Dieses Makro wird ersetzt durch den Pfad, wo alle Python-Module installiert sind, so wie /usr/lib/python2.3/site-packages. Lesen Sie zum Beispiel unter “Python-Module”.

%py_ver

Dieses Makro wird ersetzt durch die Python-Haupt-Version, so wie 2.3. Siehe “Python-Module” als Beispiel.

%remove_and_set

Dieses Makro wird verwendet, um veraltete sysconfig-Variablen zu löschen.

Syntax:

%remove_and_set [-ny] [sysconfig_filename] variable...

Das Makro %remove_and_set löschr Variablen aus /etc/rc.config und /etc/sysconfig/sysconfig_filename und setzt sie in die aktuelle Umgebung zur zukünftigen Verwendung . Wenn eine Variable nicht gefunden wird, ist sie standardmäßig auf "no" oder auf “yes”, wenn die Option -y verwendet wird.

Optionen:

• -n definiert, dass der Parameter sysconfig_filename verwendet wird (siehe unten).
• -y setzt den Standardwert auf “yes”.

Parameter:

• sysconfig_filename erzeugt ein Paar mit der Option -n und definiert den syconfig-Dateinamen. Die Paketbezeichnung (%name) wird verwendet wie ansonsten der sysconfig-Dateiname.
• variable definiert die Bezeichnung einer Variablen, zum Entfernen. Mehrere Variablen können definiert werden.

Beispiele:

• Dieses Beispiel wurde vom Paket postfix genommen:

%{fillup_and_insserv -y postfix}
if [ -f etc/sysconfig/mail ]; then
 . etc/sysconfig/mail
 if [ -n "$NULLCLIENT" ]; then
 RCTMP="etc/sysconfig/postfix.$$"
 sed "s/^POSTFIX_NULLCLIENT.*/POSTFIX_NULLCLIENT=\"$ \"/" \
 etc/sysconfig/postfix >"$RCTMP"
 mv "$RCTMP" etc/sysconfig/postfix
 fi
fi
%{remove_and_set -n mail NULLCLIENT}

Dieser Code setzt die Variable POSTFIX_NULLCLIENT von etc/sysconfig/postfix auf den Wert der veralteten Variablen NULLCLIENT von etc/sysconfig/mail. Dann wird die veraltete Variable gelöscht.

• Dieses Beispiel stammt vom Paket autofs:

%post
 %{fillup_and_insserv autofs}
 # benötigt für die Aktualisierung von 7.3 und früher
 %{remove_and_set USE_NIS_FOR_AUTOFS USE_NISPLUS_FOR_AUTOFS}
 if [ $USE_NIS_FOR_AUTOFS == "yes" ] ; then
  if `grep "^automount:" etc/nsswitch.conf | \
  grep -vqw nis` ; then
  sed "s/^automount:.*/& nis/" < etc/nsswitch.conf \
    >etc/nsswitch.conf.new
  mv etc/nsswitch.conf.new etc/nsswitch.conf
  fi
 fi
 if [ $USE_NISPLUS_FOR_AUTOFS == "yes" ] ; then
  if `grep "^automount:" etc/nsswitch.conf | \
  grep -vqw nisplus` ; then
  sed "s/^automount:.*/& nisplus/" < etc/nsswitch.conf \
    > etc/nsswitch.conf
  mv etc/nsswitch.conf.new etc/nsswitch.conf
  fi
 fi

Die veraltete Variablen USE_NIS_FOR_AUTOFS, USE_NISPLUS_FOR_AUTOFS werden gelöscht von /etc/rc_config und /etc/sysconfig/autofs und die gelöschten Werte werden verwendet, eine aktuelle Konfiguration zu modifizieren . Die gelöschten Werte können nicht in den vorherigen Beispielen verwendet werden, weil das Makro %remove_and_set fähig ist, nur Werte “yes” or “no” in der Umgebung einzurichten.

%restart_on_update

Dieses Makro startet einen Service nach einer Aktualisierung neu.

Syntax:

%restart_on_update service...

Das Makro %restart_on_update startet /etc/init.d/service try-restart, wenn es nicht unter YaST im Modus instsys läuft. Mehrere Service können definiert werden.

Dieses Makro wird gewöhnlich im Skript %postun der Pakete verwendet, die einen Service unterstützen. Es kann nicht verwendet werden, wenn nicht garantiert werden kann, dass der Service nach einer Aktualisierung funktioniert.

Beispiele:

• Dieses Beispiel wurde dem Paket rsync entnommen:

%postun
%restart_on_update rsyncd
%insserv_cleanup

• Dieses Beispiel wurde dem Paket samba entnommen (startet zwei Service neu):

%postun
%restart_on_update nmb smb
%insserv_cleanup

%run_ldconfig (deprecated)

Dieses Makro startet ldconfig, wenn es nicht von YaST gestartet wurde. YaST startet ldconfig selbst, nachdem alle ausgewählten Pakete installiert sind.

Es wurde in beiden Skripten %post und %postun von Paketen verwendet, die eine Bibliothek unterstützen. Das Makro wird abgelehnt und sollte nicht mehr verwendet werden. Stattdessen sollte /sbin/ldconfig direkt von beiden Skripten aufgerufen werden, auch von YaST, um vor dem Brechen anderer %post Skripte zu bewahren. Das könnte auf die folgende Weise getan werden:

%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig

Wenn ldconfig nicht das einzige Kommando ist, ist die Option -p nicht anwendbar. Zum Beispiel, das Skript %post könnte wie folgt aussehen:

%post
/sbin/ldconfig
[...]

%run_permissions

Dieses Makro führt SuSEconfig --module permissions aus, um di Dateierlaubnisse gemäß den System-Sicherheits-Einstellungen anzupassen.

Hinweis: Das Ausführen von SuSEconfig hat den Nachteil, dass die Erlaubnisse aller installierten Dateien angepasst werden, nicht nur die, die zum Paket gehören. Darum wird dieses Makro abgelehnt, ab openSUSE 11.4 verwenden Sie stattdessen %set_permissions.

%run_permissions muss im Skript %post von Paketen aufgerufen werden, die Dateien installieren, die von /etc/permissions.* erledigt werden. Das Paket permissions muss in PreReq sein, so wird garantiert, dass SuSEconfig.permissions zur Installationszeit zur Verfügung steht.

Ergänzend muss das Makro %verify_permissions als %verifyscript aufgerufen werden.

Beispiel:

PreReq:       permissions
[...]
%post
%run_permissions

%set_permissions

Dieses Makro passt die Berechtigungen der spezifizierten Dateien gemäß den Einstellungen der Systemsicherheit an.

Verfügbar ab openSUSE 11.4

%set_permissions muss im Skript %post von Paketen aufgerufen werden, die Dateien installieren, die von /etc/permissions.* bearbeitet werden. Das Paket permissions muss in PreReq sein, so dass garantiert ist, dass chkstat zur Installationszeit zur Verfügung steht.

Ergänzend muss das Makro %verify_permissions als %verifyscript aufgerufen werden.

Beispiel:

PreReq:       permissions
[...]
%post
%set_permissions /usr/bin/foo /bin/bar

%sles_version

Dieses Makro erweitert auf die Version von SLES, wo das Paket gebaut wird. Es ist ”7” für SLES7, ”8” für SLES8, etc. Es ist ”0” , wenn man nicht auf SLES baut.

Sehen Sie sich auch %suse_version und %ul_version an.
Ebenso en:openSUSE:Build Service cross distribution howto#Detect_a_distribution_flavor_for_special_code

Dieses Beispiel stammt vom Paket pam-modules:

%install
 [...]
 # Auf UL oder SLES verwenden wir andere Standards
 %if %sles_version >= 8
 cp $RPM_SOURCE_DIR/pam_pwcheck.conf.sles \
    $RPM_BUILD_ROOT/etc/security/pam_pwcheck.conf
 %endif

%stop_on_removal

Dieses Makro stoppt einen Service, nachdem ein Paket gelöscht wurde.

Synopse:

%stop_on_removal service...

Das Makro %stop_on_removal führt /etc/init.d/service stop aus, wenn es nicht von YaST im Modus instsys ausgeführt wird. Mehrere Service können definiert werden.

Jedes Paket, das einen Service unterstützt, der gestoppt werden kann, sollte dieses Makro bei allen Services im Skript %preun aufrufen.

Beispiele:

• Dieses Beispiel stammt vom Paket rsync:

%preun
%stop_on_removal rsyncd

• Dieses Beispiel stammt vom Paket samba (stoppt zwei Service):

%preun
%stop_on_removal smb nmb

%suse_update_config

Dieses Makro aktualisiert einiges auto-Zeug bezogene Dateien.

Verwendung:

%suse_update_config [-fcl] [dir ...]

Dieses Makro löst die folgenden Aktionen für das momentane Verzeichnis und alle Verzeichnisse, die als Parameter aufgeführt werden, aus:

• config.guess und config.sub werden durch ihre aktuellste Version /usr/share/automake*/ überschrieben.
• depcomp und missing werden hinzugefügt, wenn nicht vorhanden im ausgeführten Verzeichnis aber vorhanden in /usr/share/automake*/.
• ltconfig und ltmain.sh werden gepatcht, um beide linux-gnu und linux zu akzeptieren.
• /lib ist ersetzt durch /%_lib, in manchen Fällen in ltconfig und ltmain.sh.

Dieses Makro sollte in allen Paketen, die die problematischen Dateien verwenden, aufgerufen werden. Es werd nicht benötigt, wenn autoreconf oder aclocal, libtoolize, automake und autoconf verwendet wird, weil sie die benötigten Sachen aktualisieren.

Dieses Makro sollte auf Vorhandensein getestet werden, wenn es im Abschnitt %prep verwendet wird. Das erlaubt es, diesen Abschnitt auf anderen Distributionen auszuführen, wo das Makro nicht verfügbar ist. Siehe die unteren Beispiele.

Optionen:

• -c — nicht aktualisieren config.guess, config.sub, depcomp und missing
• -f — force, ignoriere den Zeitstempel
• -l — aktualisiere nicht ltconfig und ltmain.sh

Parameter:

• dir definiert ein zusätzliches Verzeichnis, wo Dateien aktualisiert werden sollten. Mehrere Verzeichnisse können definiert werden.

Beispiele:

• Dieses Beispiel stammt vom Paket libunicode:

%prep
%setup
%patch1
%{?suse_update_config:%{suse_update_config -f}}

%build
CFLAGS="$RPM_OPT_FLAGS" \
./configure --prefix=%prefix \
        --libdir=%prefix/%_lib \
        --sysconfdir=%sysconfdir
make

• Dieses Beispiel stammt vom Paket xosview (aktualiesiert Dateien in beiden ./ und ./config directories):

%prep
%setup -q
%patch1 -p0 -b ".serial"
[...]
%{?suse_update_config:%{suse_update_config -f config}}

%build
%ifarch ppc
export SYSTEM=powerpc-suse-linux
%else
export SYSTEM=%_target_cpu-suse-linux
%endif
(cd config/; autoconf; cp configure ../)
./configure $SYSTEM \
        --with-x \
        --enable-auto-depend \
        --enable-linux-syscalls \
        --prefix=/usr/X11R6 \
        --disable-linux-memstat
make clean

%suse_update_desktop_file

Dieses Makro aktualisiert Dateien mit der Endung .desktop.

Syntax:

%suse_update_desktop_file -c filename name comment exec icon [category]...

%suse_update_desktop_file [-inru] [-D docpath] [-N name] [-G genericname] filename [category]...

Das Makro %suse_update_desktop_file aktualisiert Übersetzungen, fügt Kategorien hinzu (benötigt, um Menüs zu sortieren) und führt einige logische Überprüfungen in der vorhandenen .desktop-Datei durch. Es benötigt das Paket update-desktop-files.

Jedes Paket, das eine .desktop-Datei unterstützt sollte das Makro für alle Grundbezeichnungen von .desktop-Dateien (ohne .desktop-Suffix) im Abschnitt %install aufrufen, nachdem die Desktop-Dateien unter /usr/share/applications oder /etc/xdg/autostart installiert wurden. Vergessen Sie nicht, das Paket update-desktop-files in der Markierung BuildRequires zu erwähnen. Es ist enthalten in den Paketen:

• gnome2-devel-packages
• gtk2-devel-packages
• kde3-devel-packages
• qt3-devel-packages
• yast2-core-devel-packages
• yast2-devel-packages

Das Paket update-desktop-files muss nicht ausdrücklich erwähnt werden in BuildRequires tag, wenn irgend eins dieser Meta-Pakete bereits vorhanden ist.

Optionen:

• -c filename name comment exec icon [category] — Erstellt eine neue .desktop-Datei, ausgelöst durch die Parameter filename, name, comment, exec, icon und category auf die folgende Weise:

[Desktop Entry]
Name=name
GenericName=comment
Type=Application
Exec=exec
Icon=icon
Categories=category;....

und installiert es als $RPM_BUILD_ROOT/usr/share/applications/filename.desktop.

• -i — Durchsucht $RPM_SOURCE_DIR und /usr/share/update-desktop-files/templates nach der Vorlage filename.desktop und installiert sie als $RPM_BUILD_ROOT/usr/share/applications/filename.desktop.
• -n — Aktualisieren Sie nicht die Übersetzungen. Es ist nützlich, wenn die Zeilen Name= und GenericName= eine Zeichenkette enthalten, der nicht übersetzt werden kann.
• -r — Ersetzt Kategorien, die in der .desktop-Datei definiert sind durch eine neue, die durch den Parameter Kategorie definiert ist. Per Standard werden die neuen Kategorien nur nach den bereits enthaltenen Kategorien hinzu gefügt.
• -u — Fügt die Zeile X-SuSE-Unimportant=true zur .desktop-Datei.
• -Ddocpath Setzt den .desktop-Datei DocPath-Eintrag.
• -Nname Setzt den .desktop-Datei Eintrag Name.
• -Ggenericname Setzt den .desktop-Datei-Eintrag GenericName.

Parameter:

• filename definiert die Dateibezeichnung der .desktop-Datei. Der Wert ist die Dateibezeichnung ohne den Suffix .desktop.
• category wird verwendet, um die Zeile Categories= in der .desktop-Datei zu modifizieren. Diese Zeile wird verwendet, um die Einträge in Untermenüs zu sortieren.

Beispiele:

• Dieses Beispiel stammt von dem Paket kvim (zeigt auch die verbundenen Teile der Markierung BuildRequires und des Abschnitts %files):

BuildRequires: ... update-desktop-files ...

%install
[...]
%suse_update_desktop_file KVim TextEditor

%files
[...]
/opt/kde3/share/applnk/*/*.desktop

Dieser Code aktualisiert Übersetzungen im bereits installierten /opt/kde3/share/applnk/Editors/KVim.desktop. Da die originale .desktop-Datei die Zeile Categories= nicht enthält, wird sie initialisiert durch Categories=TextEditor;.

• Dieses Beispiel stammt von dem Paket crack-atack: (zeigt auch die verbundenen Teile von BuildRequires tag, Source tags und %files section):

BuildRequires: ... update-desktop-files ...

Source1:      %name.desktop
Source2:      %name-xtreme.desktop
[...]

%install
[...]
%suse_update_desktop_file -i %name Game ArcadeGame
%suse_update_desktop_file -i %name-xtreme Game ArcadeGame

%files
[...]
/usr/share/applications/%name.desktop
/usr/share/applications/%name-xtreme.desktop

Dieser Code findet die zwei Vorlagen in $RPM_SOURCE_DIR und installiert sie in /usr/share/applications. Siehe den Abschnitt %files für den endgültigen Pfad. Es aktualiesiert ebenso Übersetzungen. Da die Vorlage die folgende Zeile nicht enthält Categories=, wird sie initialisiert durch Categories=Game;ArcadeGame;.

• Das Beispiel stammt vom Paket koffice:

%install
[...]  
%suse_update_desktop_file    kugar      Office Viewer
%suse_update_desktop_file -r karbon     Graphics VectorGraphics
%suse_update_desktop_file    kivio      Office FlowChart
%suse_update_desktop_file    kpresenter Office Präsentation
%suse_update_desktop_file    kchart     Office FlowChart
%suse_update_desktop_file    kspread    Office Spreadsheet
%suse_update_desktop_file -u KThesaurus Office
%suse_update_desktop_file -u kformula   Office
%suse_update_desktop_file    kword      Office WordProcessor
%suse_update_desktop_file -u koshell    Office Core-Office

Dieser Code aktualisiert Übersetzungen in den bereits installierten Desktop-Dateien. Als Ergänzung, zum Beispiel ist Kthesaurus.desktop markiert als unwichtig und die veraltete Zeile Categories= wird ersetzt durch Categories=VectorGraphics; in karbon.dekstop.

• Dieses Beispiel stammt von dem Paket qbrew:

%suse_update_desktop_file -c qbrew QBrew \
"A homebrewer's recipe calculator" \
qbrew "" Science

• Dieser Code erzeugt eine .desktop-Datei:

[Desktop Entry]
Name=QBrew
GenericName=A homebrewer's recipe calculator
Type=Application
Exec=qbrew
Icon=
Categories=Science;

Dann fügt er verfügbare Übersetzungen hinzu und installiert sie als /usr/share/applications/qbrew.desktop.

Bekannte Probleme

• Die Einstellung

Categories=Application;Office;

ist typisch für Fedora Pakete, erbringt aber Fehler in SUSE. Die Fehlermeldung sagt No sufficient Category definition - keine geeignete Kategorie definiert. Sie müssen die Flag '-r' verwenden, um die angebotene Kategorie 'Application' zu löschen und sie nur durch erlaubte Kategorien zu ersetzen. Die Option -r muss vor der Bezeichnung kommen, um wirksam zu sein.

%suse_update_desktop_file -u -r -G 'OCR Suite' %{name} Office Graphics Scanning OCR

Wenn dieses Kommando zu einer Fehlermeldung führt: /var/tmp/rpm-tmp.mkeCpx: line 54: fg: no job control versuchen Sie bitte hinzuzufügen

BuildRequires: update-desktop-files

• Die Einstellung

Version=0.5

ist typisch für Fedora-Pakete, aber liefert eine Warnung mit SUSE. Manuelles patchen ist gefordert, um die Warnung zu beheben.

%suse_version

Dieses Makro erweitert auf die Version von SUSE Linux / openSUSE, auf der das Paket gebaut ist. Es ist "1000" für SUSE Linux 10.0, "1020" für openSUSE 10.2 und so weiter.

Siehe auch %sles_version and %ul_version.
Und openSUSE:Build Service cross distribution howto#Detect_a_distribution_flavor_for_special_code

Es kann für die Versionsüberprüfung verwendet werden

 ..
 %if 0%{?suse_version} > 1100
 BuildRequires: new-package-introduced-in-11.0
 %endif
 ..

Oder um zu prüfen, ob das Paket für openSUSE gebaut wurde

 ..
 %if 0%{?suse_version}
 BuildRequires: libqt4-devel
 %else
 BuildRequires: qt4-devel
 %endif
 ...

%tcl_version

Dieses Makro erweitert auf die Version von Tcl, die für das Produkt verwendet wurde, für das das Paket gebaut wurde. Es ist "8.3" für tcl-8.3, “8.4” für tcl-8.4, etc.

Dieses Beispiel stammt vom Paket vkeybd:

%build
make PREFIX=%_prefix \
        TCL_VERSION=%tcl_version \
        XLIB="-L/usr/X11R6/lib64 -L/usr/X11R6/lib -lX11" \
        USE_LADCCA=1

%ul_version

Dieses Makro erweitert auf eine Version von United Linux, auf dem das Paket gebaut wurde. Es gilt “1” für UL 1.0 und “0” wenn nicht auf UL gebaut wurde. Anmerkung des Übersetzers: Da das Projekt United Linux bereits 2004 scheiterte, dürfte dieses Makro kaum noch von Interesse sein.

Siehe auch %sles_version und %suse_version.

Dieses Beispiel stammt vom Paket installation-images:

%build
[...]
%ifarch %ix86
themes="SuSE Home"
%else
themes=SuSE
%endif
%if %ul_version > 0
themes=UnitedLinux
%else
%if %sles_version > 0
themes="SuSE-SLES"
%endif

%verify_permissions

Dieses Makro überprüft Erlaubnisse von Dateien, die über /etc/permissions.* gemäß den Sicherheitseinstellungen des Systems verarbeitet werden.

Erlaubnis-Eigenschaften in den Paketen sollten die Einstellungen des Sicherheit Niveaus (/etc/permissions.secure) wiederspiegeln.

Um RPM von Beschwerden über die Einstellungen der Paketerlaubnisse der abzuhalten, müssen die betroffenen Dateien dementsprechend markiert werden mit z.B. %verify(not mode).

Anwendung:

%verify_permissions [-f filelist] [-e file] ...

%verify_permissions muss gemeinsam verwendet werden mit %run_permissions oder %set_permissions

Optionen:

• -e Datei — spezifiziert, welche Datei zu prüfen ist
• -f Dateiliste — spezifiziert eine Datei mit einer Liste zu prüfender Dateien (geeignet, wenn es viele gibt).

Beide Optionen können wiederholt werden.

Beispiel 1, Dateien mit variablem Modus:

%verifyscript
%verify_permissions -e /usr/bin/foo -e /bin/bar
[...]
%files
%defattr(-, root, root)
%verify(not mode) %attr(0755,root,root) /usr/bin/foo
%verify(not mode) %attr(0755,root,root) /bin/bar

Beispiel 2, Datei mit variablem Modus und Benutzer:

%verifyscript
%verify_permissions -e /etc/foo
[...]
%files
%defattr(-,root,root)
%verify(not mode user) %attr(0600,joe,root) /etc/foo

Beispiel 3, Datei mit Unterstützung für fscaps oder setuid

%verifyscript
%verify_permissions -e /bin/foo
[...]
%files
%defattr(-,root,root)
%verify(not mode caps) %attr(4755,root,root) /bin/foo