Paketbau/SUSE-Paketkonventionen/RPM-Makros

aus openSUSE, der freien Wissensdatenbank

3. RPM-Makros

Dieses Kapitel beschreibt in SUSE-Paketen genutzte vordefinierte RPM-Makros, von denen einige allgemeine RPM-Makros sind und mache SUSE-spezifische. Informationen zu anderen, allgemeinen Makros finden Sie in anderer Dokumentation wie Maximum RPM .

Ein wichtiger Unterschied zwischen RPM-Makros und normalen Linux-Kommandos ist, wie die Optionen und Parameter definiert werden. RPM bietet nur eine einfache Unterstützung zur Verarbeitung von Optionen. Eine Begrenzung besteht darin, dass alle Optionen vor den Parametern definiert werden müssen und es ist nicht einfach möglich, aus Optionen und dazugehörenden Werten gebildete Paare zu nutzen. Das Linux-Kommando top nutzt zum Beispiel die folgende Zusammenfassung:

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

Die genutzten Paare -d delay, -n iterations, -p pid und alle Parameter sind optional. Die Option vor einem Parameter gibt an, welcher Parameter wirklich genutzt wird. Dies ermöglicht solcherart Aufrufe:

Beispiel 1: top -n 20 -p 10345

Beispiel 2: top -d 1 -p 10345

Das Kommando weiß dann, dass 20 eine Anzahl von Wiederholungen ist, 1 die Verzögerung und 10345 eine pid ist.

Auf Grunde der Einschränkungen von RPM würde die Zusammenfassung eines zugehörigen RPM-Makros wie folgt aussehen:

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

Alle Optionen müssen hierbei vor den Parametern definiert werden und die Option definiert wieder, welcher Parameter wirklich genutzt wird. Das heißt, dass der potentielle Aufruf des zum obigen Beispiel gehörenden RPM-Makros folgendermaßen aussieht:

Beispiel 1: %top -d -p 5 10345

Beispiel 2: %top -d -p 1 460

3.1. %_docdir

Dieses Makro setzt das Standardverzeichnis für Dokumentation ein: /usr/share/doc/packages. Es kann mit dem Docdir Tag umdefiniert werden. Normalerweise wird es zum Installieren von Dokumentation im Abschnitt %install verwendet, falls es nicht reicht, dies mit dem Tag %doc im Abschnitt %files zu erledigen. Das Tag %doc muss bei de Verwendung von %_docdir im Abschnitt %files nicht zusätzlich angegeben werden, da dies automatisch für dieses Verzeichnis geschieht.

Das folgende Beispiel entstammt dem Paket aeolus:

%install
[...]
mkdir -p $RPM_BUILD_ROOT%{_docdir}/%{name}
cp .aeolusrc $RPM_BUILD_ROOT%{_docdir}/%{name}/aeolusrc
cp -R stops-* $RPM_BUILD_ROOT%{_docdir}/%{name}
[...]
%files
[...]
%{_docdir}/%{name}

3.2. %_infodir

Dieses Makro setzt das Standardverzeichnis für info-Seiten ein: /usr/share/info. Es wird oft mit ./configure --infodir=%_infodir mit dem %install_info-Makro und in der Dateiliste verwendet. Wie bei %_docdir muss das Tag %doc nicht zusammen mit %_infodir im Abschnitt %files angegeben werden, da es automatisch für dieses Verzeichnis geschieht.

3.3. %_lib

Dieses Makro setzt entweder lib oder lib64 ein. Die zweite Variante taucht auf 64-bit-Architekturen auf, die die parallele Ausführung von 64-bit- und 32-bit-Anwendungen unterstützen (biarch-Systeme). Auf solchen Systemen müssen zwei Varianten der selben Bibliothek nebeneinander existieren, weshalb 64-bit-Bibliotheken in lib64-Verzeichnisse und 32-bit-Bibliotheken in lib-Verzeichnisse installiert werden.

Es wird genutzt, wenn das Makro %_libdir nicht ausreicht, zum Beispiel wenn die Bibliotheken in /usr/X11R6/lib landen sollen. Es wird oft mit ./configure –libdir=/usr/X11R6/%_lib und in der Dateiliste verwendet.

3.4. %_libdir

Dieses Makro setzt auf biarch-Systemen /usr/lib64 und /usr/lib auf anderen Systemen ein. Es hat die selbe Funktion wie %_lib und wird wesentlich öfter genutzt als %_lib, da die Bibliotheken normalerweise unter /usr/lib installiert werden. Auch dieses wird oft mit ./configure –libdir=%_libdir und in der Dateiliste verwendet.

3.5. %_mandir

Dieses Makro setzt das Standardverzeichnis für manual-Seiten ein: /usr/share/man. Es wird oft mit ./configure --mandir=%_mandir und im Abschnitt %files, etwa als %_mandir/man5/*, genutzt.

So wie bei %_docdir und %_infodir ist auch hier das Tag %doc im Abschnitt %files nicht zusammen mit %_mandir nötig, da es für dieses Verzeichnis automatisch erledigt wird.

3.6. %fillup_and_insserv

Dieses Makro kann dazu genutzt werden, sysconfig-Dateien zu füllen und init-Skripte einzurichten (insserv).

Übersicht:

%fillup_and_insserv [-finpsyY] [sysconfig_filename] [init_script_name] [START_variable]] ...

Das Makro %fillup_and_insserv vereint zwei Funktionen in einem Kommando. Es wird genutzt, um Konfigurationsdateien unter /etc/sysconfig einzufügen (fill up) und um Dienste in Runleveln zu aktivieren (insserv). Der fillup-Teil erwartet eine unter /var/adm/fillup-templates/sysconfig.[sysconfig_filename][.][%name] gespeicherte Vorlage.

Das Makro wird im %post-Skript von Pakete genutzt, die ein init-Skript installieren und es standardmäßig aktivieren wollen. Es wird auch genutzt, wenn das init-Skript schon vor SL 8.0 existierte, als die START-Variablen genutzt wurden. Weiter Informationen dazu finden Sie in Abschnitt 7.8 "Installation von Init-Skripten". Vergessen Sie nicht, die verwendeten Werkzeuge im PreReq Tag anzugeben; diesem Zweck dienen die Makros %insserv_prereq und %fillup_prereq.

Optionen:

• -f überspringt den fillup-Teil.
• -i überspringt den insserv-Teil.
• -n gibt an, dass der Parameter sysconfig_filename genutzt wird (siehe unten).
• -p wird aus gründen den Rückkompatibilität ignoriert.
• -s gibt an, dass der Parameter START_variable genutzt wird (siehe unten).
• -y setzt die START-Variablen standardmäßig auf “yes”. Wird ignoriert, falls im Init-Skript X-UnitedLinux-Default-Enabled angegeben ist.
• -Y erzwingt das Setzten der SART-Variable auf “yes”. Das heißt, dass der Dienst immer aktiviert ist, ungeachtet der Einstellung vor einer Aktualisierung.

Parameter:

• sysconfig_filename bildet mit der Option -n ein Paar und definiert den Dateinamen, in den die Konfiguration gefüllt werden soll; /etc/sysconfig/sysconfig_filename.
  Zusätzlich definiert der Parameter einen Namen der Dateien mit den Vorlagen. Das Makros such nach zwei möglichen Vorlagendateien. Es bevorzugt dabei /var/adm/fillup-templates/sysconfig.sysconfig_filename.%name, falls dies verfügbar ist. andernfalls sucht es nach /var/adm/fillup-templates/sysconfig.sysconfig_filename. Die längere Variante muss genutzt werden, falls mehere Pakete in die gleiche Konfigurationsdatei schreiben.

Standardmäßig (die Option -n bleibt ungenutzt) ist /var/adm/fillup-templates/sysconfig.%name die Vorlage und die sysconfig-Zieldatei ist /etc/sysconfig/%name.

• init_script_name definiert den Namen des von insserv berarbeiteten Init-Skripts. Muss angegeben werden, wenn die Option -i nicht genutzt wird. Es können mehere Init-Skriptnamen angegeben werden (siehe Beispiele weiter unten).
• START_variable bildet mit der Option -s ein Paar und definiert den Namen der START-Variablen neu, welche bei einer Aktualisierung geprüft wird. Daneben bildet er Paare mit dem Parameter init_script_name. Alle Paare müssen vollständig sein, falls die Option -s gesetzt ist und mehrere Init-Skripte auf einmal verarbeitet werden (sie Beispiel weiter unten). Bei den Hinweisen in Kapitel 7.8 "Installation von Init-Skripten" finden Sie weitere Informationen über START-Variablen.
  Standardmäßig (die Option -s bliebt ungenutzt) wird der Name der START-Variablen vom Parameter init_script_name abgeleitet. Konkret wird dabei der Wert von init_script_name in Großbuchstaben umgewandelt und erhält die Vorsilbe START_ (siehe Beispiele weiter unten).

Beispiele:

1. Dieses Beispiel entstammt dem Paket mailman (zeigt auch die zugehörigen Teile des PreReq Tag):

PreReq: ... %insserv_prereq  %fillup_prereq ...

%post
%{fillup_and_insserv mailman}

Es füllt die Konfiguratiosndatei /etc/sysconfig/mailman aus der Vorlage /var/adm/fillup-templates/sysconfig.mailman. Es lässt insserv über /etc/init.d/mailman laufen, indem die Variable START_MAILMAN geprüft wird.

2. Diese Beispiel entstammt dem Paket hwinfo (zeigt auch die zugehörigen Teile des PreReq Tag):

PreReq:       ... %insserv_prereq

%post
[...]
%{fillup_and_insserv -fy hwscan}

Es lässt insserv über /etc/init.d/hwscan laufen und aktiviert den Dienst standardmäßig. Beachten Sie, dass sich hier nur der insserv-Teil unter PreReq befindet, da der fillup-Teil mit der Option -f übersprungen wird.

3. Dieses Beispiel entstammt dem Paket openssh:

%{fillup_and_insserv -n -y ssh sshd}

Es füllt die Konfigurationsdatei /etc/sysconfig/ssh auf. Die Vorlage wird entweder /var/adm/fillup-templates/sysconfig.ssh.openssh oder /var/adm/fillup-templates/sysconfig.ssh entnommen, wobei die erste Vorlage bevorzugt wird. Es lässt insserv über /etc/init.d/sshd laufen, indem es die Variable START_SSHD prüft. Der Dienst wird standardmäßig aktiviert.

4. Dieses Beispiel entstammt dem Paket apache:

%{fillup_and_insserv -s apache START_HTTPD}

Es füllt die Konfigurationsdatei /etc/sysconfig/apache aus der Vorlage /var/adm/fillup-templates/sysconfig.apache. Es lässt insserv über /etc/init.d/apache laufen, indem es die Variable START_HTTPD prüft.

5. Dieses Beispiel entstammt dem Paket openldap2:

%{fillup_and_insserv -n openldap ldap slurpd}

Es füllt die Konfigurationsdatei /etc/sysconfig/openldap. Die Vorlage wird entweder /var/adm/fillup-templates/sysconfig.openldap.openldap2 oder /var/adm/fillup-templates/sysconfig.openldap entnommen, wobei die erste Datei bevorzugt wird. Es lässt insserv über /etc/init.d/ldap laufen, indem es die Variable START_LDAP überprüft. Dazu lässt es insserv über /etc/init.d/slurpd laufen, indem es die Variable START_SLURPD überprüft.

6. Dieses Beispiel zeigt die Verwendung der Option -s für mehere Init-Skripte:

%{fillup_and_insserv -n -s openldap ldap START_LDAP slurpd START_SLURPD}

Hierbei wird das selbe gemacht, wie im vorherigen Beispiel. Der einzige Unterschied besteht darin, dass die START-Variablen hier explizit angegeben sind.

3.7. %fillup_only

Dieses Makro kann genutzt werden, um sysconifg-Dateien aufzufüllen.

Übersicht:

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

Das Makro %fillup_only wird genutzt, um die Variablen aus ein Vorlage /var/adm/fillup-templates/sysconfig.sysconfig_filename[-suffix] ein eine Konfigurationsdatei /etc/sysconfig/sysconfig_filename zu füllen (fill up). Die Basisfunktion ähnelt der von %fillup_and_insserv -i, allerdings erlaubt sie es auch, Konfigurationsdateien in Unterverzeichnissen von /etc/sysconfig zu verändern.

Das Makro wird typischerweise im %post-Skript genutzt. Vergessen Sie nicht, die genutzten Dienstprogramme im PreReq Tag anzugeben. Für diesen Zweck gibt es das Makro %fillup_prereq.

Optionen:

• -a nutzt den Paketnamen als Endsilbe für die Datei mit der sysconfig-Vorlage.
• -d gibt an, dass der Parameter sysconf_subdir genutzt wird (siehe unten).
• -n gibt an, dass der Parameter sysconfig_filename genutzt wird (siehe unten).
• -s gibt an, dass der Parameter suffix genutzt wird (siehe unten).

Parameter:

• sysconfig_filename bildet mit der Option -n ein Paar und definiert den Namen der sysconfig-Datei und einen Namen der Vorlagendatei.
  Standardmäßig (bei ungenutzter Option -n) wird stattdessen de Paketname genutzt. So wird dann die Voralge /var/adm/fillup-templates/sysconfig.%name zum Auffüllen von /etc/sysconfig/%name verwendet.
• sysconfig_template_filename_suffix bildet mit der Option -s ein Paar und definiert eine Endsilbe für den Dateinamen der Vorlage.
• sysconfig_subdir bildet mit der Option -d ein Paar und definiert ein Unterverzeichnis von /etc/sysconfig, in welchem sich die sysconfig-Dateien befinden.

Beispiele:

1. Dieses Beispiel entstammt dem Paket tetex (und zeigt auch die zugehörigen Teile im PreReq Tag):

PreReq:       %fillup_prereq ...

%post
%{fillup_only}

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

2. Dieses Beispiel entstammt dem Paket man:

%{fillup_only -an cron}

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

3. Dieses Beispiel entstammt dem Paket dhcp:

%{fillup_only -ans syslog dhcpd}

Es füllt die Konfigurationsdatei /etc/sysconfig/syslog mit dem Inhalt der Vorlage /var/adm/fillup-templates/sysconfig.syslog-dhcpd auf.

4. Dieses Beispiel entstammt dem Paket samba:

%fillup_only -nsd dhcp samba-client network

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

3.8. %find_lang

Dieses Makro hilft, sprachabhängige Dateien mit dem zuigehörigen %lang Tag in der Dateiliste zu markieren.

Übersicht:

%find_lang name [filelist]

Das Makro %find_lang durchsucht die Verzeichnisse /usr/share/locale und locale/*/LC_MESSAGES nach name.mo-Dateien. Außerdem durchsucht es die Verzeichnisse gnome/help/name und kde*/share/doc/HTML/*/name nach lokalisierter Dokumentation. Aus diesen Ergebnissen wird die Datei filelist erstellt, in der die geunfendenen Dateien zusammen mit dem zugehörigen %lang(locale) Tag und (falls passend) dem %doc Tag aufgelistet werden. So eine Datei kann dann über die Option -f an das %files Tag weitergeleitet werden. Weiter unten finden Sie ein Beispiel dazu.

Es wird empfohlen, dieses Makro nur zu verwenden, wenn das BuildRoot Tag definiert ist, da ansonsten das ganze System durchsucht wird.

Parameter:

name definiert den Namen von .mo-Dateien und den Namen der Unterverzeichniss, in denen lokalisierte Dokumentation für GNOME und KDE gespeichert ist. Falls der Parameter filelist nicht definiert ist, wird die Datei mit der Dateiliste ebenfalls nach dem hier angegebenen Namen benannt.

filelist definiert den Namen der Datei, in welcher die Liste der gefundenenen Dateien gespeichert wird. name.lang wird verwendet, falls nichts angegeben wird.

Dieses Beispiel entstammt derm Paket pan:

%install
make -i DESTDIR=$RPM_BUILD_ROOT install
%find_lang %{name}              # generate a special file list

%files -f %{name}.lang          # use the special file list
%defattr(-,root,root)           # list the other files
%doc README ChangeLog AUTHORS TODO COPYING CREDITS
%attr(755,root,root) %{prefix}/bin/pan
[...]

3.9. %insserv_cleanup

Dieses Makro wird genutzt, um nach dem Entferenen eines Pakets insserv aufzuräumen und sollte von jedem Paket, dass ein Init-Skript enthält, im %postun-Skript genutzt werden.

Dieses Beispiel entstammt dem Paket openldap2:

%postun
%restart_on_update ldap slurpd
%insserv_cleanup

3.10. %insserv_force_if_yast

Dieses Makro ist ein einfacher Aufruf des Dienstprogramms insserv, falls das Paket nicht durch YaST installiert wird. Falls YaST genutzt wird, lautete der Aufruf insserv -f. Dies hilft, Fehler bei Paketinstallationen "aus der Reihe" zu vermeiden.

Das Makro wird im %post-Skript von Paketen genutzt, die ein Init-Skript installieren und dies standardmäßig aktivieren wollen. Es wird auch beim Verwenden der START-Variablen genutzt, wenn das Init-Skript schon vor SL 8.0 existierte. Siehe Kapitel 7, Abschnitt 8 "Installation von Init-Skripten" für weitere Details. Vergessen Sie nicht, die vernwendeten Dienstprogramme im PreReq Tag einzutragen, wofür die Makros %insserv_prereq und %fillup_prereq bereitstehen.

Dieses Beispiel entstammt dem Unterpaket Paket nscd des Pakets glibc (und zeigt auch das zugehörige PreReq Tag an):

%package -n nscd
[...]
PreReq:       %insserv_prereq

%post -n nscd
%{insserv_force_if_yast nscd}

3.11. %install_info

Dieses Makro aktualisiert Verzeichniseinträge für info-Datein.

Übersicht:

%install_info install_info_options

Das Makro %install_info lässt bin/install-info mit einigen zusätzlichen Tests laufen und akzeptiert dabei jede Option des install-info-Dienstprogramms. Mit man install-info erhalten Sie weitere Details dazu.

Jedes Paket, dass info-Seiten enthält, sollte dieses Makro im %post-Skript aufrufen. Vergessen Sie nicht, die verwendeten Dienstprogramme im PreReq Tag aufzuführen. Für diesen Zweck steht das Makro %install_info_prereq bereit.

Beispiele:

1. Dieses Beispiel entstammt dem Paket zsh (und zeigt auch das zugehörige PreReq Tag):

PreReq: %install_info_prereq
[...]
%post
%install_info --info-dir=%_infodir %_infodir/%name.info.gz

2. Dieses Beispiel entstammt dem Paket rplay (einem Paket mit mehreren Info-Seiten). Das Beispiel zeigt auch das zugehörige PreReq Tag:

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

3.12. %install_info_delete

Dieses Makro entfernt Verzeichniseinträge für info-Dateien.

Übersicht:

%install_info_delete install_info_options

Das Makro %install_info_delete ist das Gegenstück zum Makro %install_info. Es führt sbin/install-info --quiet –delete mit einigen zusätzlichen Tests aus, wobei es jede Option des install-info-Dienstprogramms nutzen kann. Mit man install-info erhalten Sie weitere Details.

Jedes Paket, dass info-Seiten bereitstellt, sollte dieses Makro im %postun-Skript aufrufen. Vergessen Sie dabei nicht, die verwendeten Dienstprogramme im PreReq-Tag aufzuführen, wozu sich das Makro %install_info_prereq nutzen lässt.

Beispiele:

1. Dieses Beispiel entstammt dem Paket zsh (und zeigt auch das zugehörige PreReq Tag):

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

2. Dieses Beispiel entstammt dem Paket rplay (einem Paket mit mehreren info-Seiten). Das Beispiel zeigt auch das zugehörige PreReq Tag):

PreReq: %install_info_prereq
[...]
%postun
%install_info_delete --info-dir=%{_infodir} %{_infodir}/%{name}.info.gz
%install_info_delete --info-dir=%{_infodir} %{_infodir}/RPLAY.info.gz
%install_info_delete --info-dir=%{_infodir} %{_infodir}/RPTP.info.gz
%install_info_delete --info-dir=%{_infodir} %{_infodir}/librplay.info.gz

3.13. %perl_archlib

Dieses Makro setzt den Pfad ein, unter dem die architekturspezifischen Teile von Perl installiert sind, beispielsweise /usr/lib/perl5/5.8.5/i586-linux-thread-multi.

Es wird normalerweise nur vom perl-Paket selbst und vom Makro <class="systemitem">%perl_process_packlist</code> genutzt. Siehe weiter unten.

3.14. %perl_make_install

Dieses Makro ruft make install auf verschiedenen Produkten korrekt auf. Vor SL 9.0 sah der normale Weg wie folgt aus:

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

Für 9.0 und spätere Versionen:

make DESTDIR=$RPM_BUILD_ROOT install_vendor

Mit dem Makro %perl_make_install wird dies für die jeweilige Version korrekt erledigt.

Dieses Beispiel entstammt dem Paket perl-URI:

%install
%perl_make_install

3.15. %perl_process_packlist

Dieses Makro bereitet einige, zu Perl-Modulen gehörende Dateien, für das finale Paket vor, wobei es die folgenden Aktionen durchführt:

• Entfernt $RPM_BUILD_ROOT von %perl_archlib/perllocal.pod und benennt die Datei in eine paketspezifische Datei um. Weiter untern finden Sie mehr Details
• Sucht nach installierten .packlist-Dateien und entfernt von diesen $RPM_BUILD_ROOT.

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

Die Datei %perl_archlib/perllocal.pod muss umbenannt werden, da sie Informationen über zusätzlich installierte Perl-Module enthält und von mehreren Paketen am gleichen Platz installiert werden kann. Au diesem Grund wird Sie umbenannt und ein spezielles SuSEconfig-Modul, /sbin/conf.d/SuSEconfig.perl, fügt die Informationen nach der Installation eines Pakets der System-%perl_archlib/perllocal.pod hinzu.

Das Beispiel entstammt dem Paket perl_URI:

%install
%perl_make_install
%perl_process_packlist

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

3.16. %perl_sitearch

Dieses Makro setzt den Pfad ein, unter dem architekturspezifische Teile von Perl-Modulen von einem lokalen Administrator installiert werden (/usr/lib/perl5/site_perl/5.8.5/i586-linux-thread-multi). Die Pakete die mit SUSE Linux ausgeliefert werden nutzen stattdessen den Pfad, der von %perl_vendorarch definiert wird, weiteres dazu weiter unten.

3.17. %perl_sitelib

Dieses Makro setzt den Pfad ein, unter dem architekturunabhängige Teile von Perl-Modulen von einem lokalen Administrator installiert werden (/usr/lib/perl5/site_perl/5.8.5). Die Pakete die mit SUSE Linux ausgeliefert werden nutzen stattdessen den Pfad, der von %perl_vendorlib definiert wird; weiteres dazu weiter unten.

3.18. %perl_vendoarch

Dieses Makro setzt den Pfad ein, unter dem architekturspezifische Teile von Perl-Modulen von Linux-Anbietern gespeichert werden (/usr/lib/perl5/vendor_perl/5.8.5/i586-linux-thread-multi). Das Makro wird meistens in der Dateiliste eingesetzt.

Das Beispiel entstammt dem Paket perl-URI:

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

Dieser Pfad wird seit SL 9.0 benutzt. Bis dahin wurden die Perl-Module unter /usr/lib/perl5/site_perl gespeichert, indem das Makro %perl_sitearch genutzt wurde. Das Verzeichnis site_perl ist nun für Module gedacht, die von einem lokalen Administrator installiert werden (siehe auch weiter oben unter %perl_sitearch).

3.19. %perl_vendorlib

Dieses Makro setzt den Pfad ein, unter dem architekturunabhängige Teile von Perl-Modulen von einem Linux-Anbieter installiert werden (/usr/lib/perl5/vendor_perl/5.8.5). Das Makro wird zumeist in der Dateiliste genutzt.

Dieses Beispiel entstammt dem Paket perl-URI:

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

Dieser Pfad wird seit SL 9.0 genutzt. Bis dahin wurden die Perl-Module unter /usr/lib/perl5/site_perl gespeichert, indem das Makro %perl_sitearch genutzt wurde. Das Verzeichnis site_perl ist nun für Module gedacht, die vom lokalen Administrator installiert werden (siehe auch weiter oben unter %perl_sitelib).

3.20. %perl_version

Dieses Makro setzt die zum Bauen verwendete Version von Perl ein, beispielsweise 5.8.5. Es wird Paketen, die ein Perl-Modul enthalten, dazu genutzt, die Abhängigkeit zu Perl zu definieren.

Normalerweise wird es auf dem folgenden Weg genutzt. Dieses Beispiel entstammt dem Paket perl-URI:

Requires:     perl = %{perl_version}

3.21. %py_incdir

Dieses Makro setzt den Pfad ein, unter dem die Python header-Dateien installiert sind, beispielsweise /usr/include/python2.3. Weitere Details dazu finden Sie in Kapitel 10.4 "Python-Module".

3.22. %py_libdir

Dieses Makro setzt den Pfad ein, unter dem Python-Module installiert sind, beispielweise /usr/lib/python2.3. Weitere Details dazu finden Sie in Kapitel 10.4 "Python-Module".

3.23. %py_requires

Dieses Makro setzt die Tags PreReq und BuildRequires ein und definiert dort Abhängigkeiten zur selben Python-Hauptversion, wie sie beim Bau verwendet wird. Weitere Details dazu finden Sie in Kapitel 10.4 "Python-Module".

3.24. %py_sitedir

Dieses Makro setzt den Pfad ein, unter dem alle Extra-Python-Module installiert sind, beispielsweise /usr/lib/python2.3/site-packages. Weitere Details dazu finden Sie in Kapitel 10.4 "Python-Module".

3.25. %py_ver

Dieses Makro setzt die Python-Hauptversion ein, beispielsweise 2.3. Weitere Details dazu finden Sie in Kapitel 10.4 "Python-Module".

3.26. %remove_and_set

Dieses Makro wird genutzt, um überflüssige sysconfig-Variablen zu entfernen.

Übersicht:

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

Das Makro %remove_and_set entfernt Variablen aus /etc/rc.config und /etc/sysconfig/sysconfig_filename und setzt sie für weitere Behandlung in der aktuellen Umgebung. Falls eine Variable nicht gefunden wird, wird sie standardmäßig auf "no" gesetzt oder im Fall der Nutzung der Option -y auf “yes”.

Optionen:

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

Parameter:

• sysconfig_filename bildet mit der Option -n ein Paar und definiert den sysconfig-Dateinamen; andernfalls wird der Paketname (%name) für den sysconfig-Dateinamen genutzt.
• variable definiert den Namen einer zu entfernenden Variablen, wobei mehre Variablen angegeben werden können.

Beispiele:

1. Dieses Beispiel entstammt dem Paket postfix:

%{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 Kode setzt die Variable POSTFIX_NULLCLIENT aus etc/sysconfig/postfix auf den Wert der überflüssigen Variable NULLCLIENT aus etc/sysconfig/mail. Danach wird die überflüssige Variable entfernt.

2. Dieses Beispiel entstammt dem Paket autofs:

%post
 %{fillup_and_insserv autofs}
 # needed for update from 7.3 and before
 %{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 überflüssigen Variablen USE_NIS_FOR_AUTOFS und USE_NISPLUS_FOR_AUTOFS werden aus /etc/rc_config und /etc/sysconfig/autofs entfernt und die entfernten Werte werden zur Modifizierung einer aktuellen Konfiguration genutzt.

Die erkannten Werte können im vorherigen Beispiel nicht genutzt werden, da dass Makro %remove_and_set nur die Werte “yes” oder “no” in der Umgebung setzen kann.

3.27. %restart_on_update

Dieses Makro startet einen Dienst nach einer Aktualisierung neu.

Übersicht:

%restart_on_update service...

Das Makro %restart_on_update führt /etc/init.d/service try-restart aus, falls es nicht unter YaST im instsys-Modus läuft. Es können mehrere Dienste angegeben werden.

Dieses Makro wird normalerweise im %postun-Skript von Paketen genutzt, die einen Dienst anbieten. Es kann jedoch nicht genutzt werde, wenn nicht sicher ist, ob der Dienst nach einer Aktualisierung auch funktioniert.

Beispiele:

1. Dieses Beispiel entstammt dem Paket rsync:

%postun
%restart_on_update rsyncd
%insserv_cleanup

2. Dieses Beispiel entstammt dem Paket samba (startet zwei Dienste neu):

%postun
%restart_on_update nmb smb
%insserv_cleanup

3.28. %run_ldconfig (auslaufend)

Dieses Makro führt ldconfig aus, falls es nicht von YaST aus aufgerufen wird. YaST führt ldconfig selber aus, nachdem alle ausgewählten Pakete installiert sind.

Es wurde in %post- und %postun-Skripten von Paketen genutzt, die eine Bibliothek bereitstellen. Dieses Makro wird nicht weiter unterstützt und sollte nicht mehr genutzt werden. Stattdessen sollte /sbin/ldconfig in beiden Skripten direkt aufgerufen werden, auch unter YaST, um andere %post-Skripte nicht zu brechen. Dies kann folgendermaßen ablaufen:

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

Falls ldconfig nicht das einzige Kommando ist, ist die Option -p nicht nutzbar. Das %post-Skript könnte dann etwa so aussehen:

%post
/sbin/ldconfig
[...]

3.29. %run_permissions

Dieses Skript fixiert die Berechtiungen für problematische Dateien, um sich an die Sicherheitseinstellungen des Systems zu halten. Dazu muss das Paket permissions installiert sein.

Es sollte im %post-Skript von Paketen aufgerufen werden, die eine Datei installieren, deren Zgriffsberechtigung in /etc/permissions.{easy,secure} oder /etc/permissions.d/%name.{easy,secure} definiert ist. Vergessen Sie nicht, dass Paket permissions im PreReq Tag anzugeben.

Es wird normalerweise zusammen mit dem Makro %verify_permissions verwendet.

Dieses Beispiel entstammt dem Paket xtetris (zeigt auch das zugehörige PreReq Tag):

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

3.30. %sles_version

Dieses Makro setzt die SLES-Version ein, auf dem das Paket gebaut wird. Dabei wird ”7” für SLES7, ”8” für SLES8, usw. eingesetzt. Es ist ”0” wenn nicht auf SLES gebaut wird.

Siehe auch %suse_version und %ul_version.

Dieses Beispiel entstammt dem Paket pam-modules:

%install
 [...]
 # On UL or SLES, we have other defaults
 %if %sles_version >= 8
 cp $RPM_SOURCE_DIR/pam_pwcheck.conf.sles \
    $RPM_BUILD_ROOT/etc/security/pam_pwcheck.conf
 %endif

3.31. %stop_on_removal

Dieses Makro stoppt einen Dienst, nachdem ein paket entfernt wurde.

Übersicht:

%stop_on_removal service...

Das Makro %stop_on_removal führt /etc/init.d/service stop falls es nicht unter YaST im instsys-Modus läuft. Es können mehere Dienste angegeben werden.

Jedes Paket, dass einen Dienst bereitstellt, der gestoppt werden kann, sollte dieses im %preun-Skript für all diese Dienste aufrufen.

Beispiele:

1. Dieses Beispiel entstammt dem Paket rsync:

%preun
%stop_on_removal rsyncd

2. Dieses Beispiel entstammt dem Paket samba (stoppt zwei Dienste):

%preun
%stop_on_removal smb nmb

3.32. %suse_update_config

Dieses Makro aktualisiert eineige Dateien mit automatischem Zeug.

Nutzung:

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

Dieses Makro führt für das aktuelle und für alle als Parameter übergebenen Verzeichnisse die folgenden Aktionen aus:

• config.guess und config.sub werden durch ihre aktuellsten Versionen aus /usr/share/automake*/ überschrieben.
• depcomp und missing werden hinzugefügt, falls sie in /usr/share/automake*/ aber nicht im verarbeiteten Verzeichnis vorhanden sind.
• ltconfig und ltmain.sh werden gepatched, um linux-gnu und linux zu akzeptieren.
• /lib wird bei manchen Erscheinungen in ltconfig und ltmain.sh durch /%_lib ersetzt.

Dieses Makro sollte in allen Paketen genutzt werden, die die problematischen Dateien nutzen. Es ist jedoch nicht notwendig, wenn autoreconf oder aclocal, libtoolize, automake und autoconf genutzt werden, da diese in der Lage sind, die benötigten Dinge zu aktualisieren.

Wenn dieses Makro im Abschnitt %prep genutzt wird, sollte seine Existenz geprüft werden. Dies erlaubt es, diesen Abschnitt auch auf anderen Distributionen auszuführen, auf denen dieses Makro nicht verfügbar ist. Ein Beispiel dazu erhalten Sie unten.

Optionen:

• -c — config.guess, config.sub, depcomp und missing nicht aktualisieren
• -f — forcieren, Zeitstempel ignorieren
• -l — ltconfig und ltmain.sh nicht aktualisieren

Parameter:

• dir gibt ein zusätzliches Verzeichnis an, in dem die Dateien aktualisiert werden solln, wobei mehrer Verzeichnisse angegeben werden können.

Beispiele:

1. Dieses Beispiel entstammt dem 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

2. Dieses Beispiel entstammt dem Paket xosview (aktualisiert Dateien in den Verzeichnissen ./ und ./config):

%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

3.33. %suse_update_desktop_file

Dieses Makro aktualisiert .desktop-Dateien.

Übersicht:

%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 zum Sortieren der Menüs) und führt einige Plausibilitätsprüfungen an den angegebenen .dekstop-Dateien durch. Es benötigt das Paket update-desktop-files.

Jedes Paket, dass eine .desktop-Datei mitbringt, sollte dieses Makro im Abschnitt %install für alle .desktop-Dateien aufrufen. Vergessen Sie dabei nicht, dass Paket update-desktop-files im BuildRequires Tag einzutragen, welches in den folgenden Metapaketen enthalten ist:

• 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 explizit im BuildRequires Tag eingetragen werden, falls sich dort schon eins der Metapakete befindet.

Optionen:

• -c filename name comment exec icon [category] — erstellt eine neue .desktop-Datei, initialisiert durch die Parameter filename, name, comment, exec, icon und category, die folgendermaßen aussieht:

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

und installiert sie 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 diese als $RPM_BUILD_ROOT/usr/share/applications/filename.desktop.
• -n — Die Übersetzungen werden nicht aktualisiert. Dies ist nützlich, falls die Zeilen Name= und GenericName= eine Zeichenkette enthalten, die nicht übersetzt werden kann.
• -r — Ersetzt die in der .desktop-Datei definierten Kategorien durch die im Parameter category angegebenen. Standardmäßig werden die neuen Kategorien lediglich an die schon enthaltenen Kategorien angehängt.
• -u — Fügt der .desktop-Datei die Zeiel X-SuSE-Unimportant=true hinzu.
• -Ddocpath Setzt in der .desktop-Datei den Eintrag DocPath.
• -Nname Setzt in der .desktop-Datei den Eintrag Name.
• -Ggenericname Setzt in der .dekstop-Datei den Eintrag GenericName.

Parameter:

• filename gibt einen Dateinamen für die .desktop-Datei an. Als Wert wird der Dateinamen ohne .desktop-Endung genommen.
• category wird genutzt, um die Zeile Categories= in der .desktop -Datei hinzuzufügen oder zu ändern. Diese Zeile wird genutzt, um Einträge in Untermenüs zu sortieren.

Beispiele:

1. Dieses Beispiel entstammt dem Paket kvim (zeigt auch die zugehörigen Teile des BuildRequires Tag und den Abschnitt %files):

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

%install
[...]
%suse_update_desktop_file KVim TextEditor

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

Dieser Kode aktualisiert Übersetzungen im bereits installierten /opt/kde3/share/applnk/Editors/KVim.desktop. Da die originale .desktop-Datei die Zeile Categories= nicht besitzt, wird sie mit Categories=TextEditor; initialisiert.

2. Dieses Beispiel entstammt dem Paket crack-atack: (zeigt auch die zugehörigen Teile der BuildRequires und Source Tags sowie den Abschnitt %files):

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 Kode findet die zwei Vorlagen in $RPM_SOURCE_DIR und installiert sie unter /usr/share/applications. Im Abschnitt %files sehen Sie den endgültigen Pfad. Außerdem werden Übersetzungen aktualisiert. Da die Vorlagen die Zeile Categories= nicht enthalten, wird diese mit Categories=Game;ArcadeGame; initialisiert.

3. Dieses Beispiel entstammt dem Paket koffice:

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

Dieser Kode aktualisiert Übersetzungen in bereits installierten .desktop-Dateien. Zusätzlich wird beispielsweise Kthesaurus.desktop als unwichtig (unimportant) markiert und die überflüssige Zeile Categories= wird in karbon.dekstop durch Categories=VectorGraphics; ersetzt.

4. Dieses Beispiel entstammt dem Paket qbrew:

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

5. Dieser Kode erstellt eine .desktop-Datei:

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

Danach werden verfügbare Übersetzungen hinzugefügt und die Datei wird als /usr/share/applications/qbrew.desktop installiert.

3.34. %suse_version

Dieses Makro setzt die Version des SUSE Linux ein, auf dem das Paket gebaut wird. Der Wert ist ”800” für SUSE Linux 8.0, ”810” für 8.1, usw.

Siehe auch %sles_version und %ul_version.

Dieses Beispiel entstammt dem Paket binutils:

%prep
 [...]
 # experimental stuff not for the older distributions
 %if %suse_version > 820
 %patch6
 %endif

3.35. %tcl_version

Dieses Makro setzt die Version von Tcl ein, die auf dem System verwendet wird, auf dem das Paket gebaut wird. Der Wert ist "8.3" für tcl-8.3, “8.4” für tcl-8.4, usw.

Dieses Beispiel entstammt dem Paket vkeybd:

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

3.36. %ul_version

Dieses Makro setzt die Version des United Linux ein, auf dem das Paket gebaut wird. Der Wert ist “1” für UL 1.0 und “0” wenn es nicht auf UL gebaut wird.

Siehe auch %sles_version und %suse_version.

Dieses Beispiel entstammt dem 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

3.37. %verify_permissions

Dieses Makro hilft dabei, Zugriffsrechte von Dateien zu prüfen, die von den Sicherheitseinstellungen des Systems abhängen.

Nutzung:

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

Jedes Paket, dass Dateien enthält für die in /etc/permissions oder /etc/permissions.easy andere Berechtigungen definiert sind als in /etc/permissions.secure, sollte dieses Makro im Abschnitt %verifyscript aufrufen.

Es wird normalerweise zusammen mit dem Makro %run_permissions genutzt. Die problematischen Dateien werden in der Dateiliste für gewöhnlich mit %verify(not mode) markiert (siehe Beispiele weiter unten).

Optionen:

• -f filelist — Gibt eine Datei mit einer List zu prüfender Dateien an.
• -e file — gibt eine einzelne zu prüfende Datei an.

Beide Optionen können wiederholt werden.

Beispiele:

1. Dieses Beispiel entstammt dem Paket xtetris (zeigt auch den Teil mit %run_permissions):

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

%verifyscript
%verify_permissions -e /usr/X11R6/bin/xtetris

%files
%defattr(-, root, root)
%verify(not mode) %attr(0755,games,games) /usr/X11R6/bin/xtetris

2. Dieses Beispiel entstammt dem Paket cron:

%verifyscript
%verify_permissions -e /etc/crontab -e /usr/bin/crontab
[...]
%files
[...]
%verify(not mode) %config(noreplace) /etc/crontab
[...]
%verify(not mode) %attr (4750,root,trusted) /usr/bin/crontab

3. This example is taken from the package gnome-games:

%verifyscript
%verify_permissions -f %prefix/share/gnome-games/sgidlist
[...]
%files -f %files -f %{name}.lang
%defattr(-,root,root)
%doc AUTHORS COPYING ChangeLog NEWS README
%defattr (0755, games, games)
%verify(not mode) %{prefix}/bin/glines
%verify(not mode) %{prefix}/bin/gnibbles
%verify(not mode) %{prefix}/bin/gnobots2
[...]
%verify(not mode) %{prefix}/bin/same-gnome
%defattr (-, root, root)
%{prefix}/bin/blackjack