Packaging/SUSE Package Conventions/RPM Macros

From openSUSE

3. RPM Macros

This section describes predefined RPM macros used in the SUSE packages. Some of them are generic RPM macros. Some are SUSE-specific macros. For other existing generic macros, other documentation should be consulted, such as Maximum RPM.

One important difference between RPM macros and normal Linux commands is how the options and parameters are defined. RPM provides only a simple support for processing options. One limitation is that all options must be defined before parameters and it is not simply possible to use pairs created from an option and a related value. For example, the Linux command top uses the following synopsis:

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

The used pairs -d delay, -n iterations, -p pid and all the parameters are optional. The option before a parameter defines which parameter is really used on the command line. This makes it possible to call:

Example 1: top -n 20 -p 10345

Example 2: top -d 1 -p 10345

and the command knows that 20 is a number of iterations, 1 is a delay and 10345 is a pid.

Due to the limitation in RPM, the synopsis of a related RPM macro would look like:

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

All the options must be defined before parameters and the option again defines which parameter is really used. This means that the related call of the potential RPM macro of the examples above would be:

Example 1: %top -n -p 5 10345

Example 2: %top -d -p 1 460

3.1. %_docdir

This macro is substituted by the default directory for documentation, /usr/share/doc/packages. It may be redefined by the Docdir tag. Usually, it is used to install a documentation in the section %install if it is not sufficient to do it with the tag %doc in the section %files. The tag %doc need not be used together with %_docdir in the section %files. It is done automatically for this directory.

This example is taken from the package 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

This macro is substituted by the default directory for info pages, /usr/share/info. It is often used with ./configure --infodir=%_infodir with the the %install_info macro and in the file list. As with %_docdir, the tag %doc need not be used together with %_infodir in the section %files. It is done automatically for this directory.

3.3. %_lib

This macro substitutes for either lib or lib64. The second variant appears on 64-bit architectures which support running both, 64-bit and 32-bit, applications in parallel (biarch systems). On such systems, two variants of the same libraries must coexist. Therefore the 64-bit libraries are installed in lib64 directories and 32-bit libraries in the lib directories.

It is used when the macro %_libdir is not sufficient, for example, when the libraries go to /usr/X11R6/lib. It is often used with ./configure –libdir=/usr/X11R6/%_lib and in the file list.

3.4. %_libdir

This macro is substituted by /usr/lib64 on biarch systems and /usr/lib on others. It has the same function as %_lib and is used even more often than %_lib because the libraries usually are installed into /usr/lib. Again, it is often used with ./configure --libdir=%_libdir and in the file list.

3.5. %_mandir

This macro is substituted by the default directory for manual pages, /usr/share/man. It is often used with ./configure --mandir=%_mandir and in the section %files, like %_mandir/man5/*.

As with %_docdir and %_infodir, the tag %doc need not be used together with %_mandir in the section %files. It is done automatically for this directory.

3.6. %fillup_and_insserv

This macro can be used to fill up sysconfig files and insserv init scripts.

Synopsis:

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

The macro %fillup_and_insserv combines two functions in one command. It is used to insert (fill up) config files in /etc/sysconfig and to enable (insserv) services in runlevels. The fillup part assumes a template stored in /var/adm/fillup-templates/sysconfig.[sysconfig_filename][.][%name].

The macro is used in %post script of packages that install an init script and want to enable it by default. It is also used if the init script existed prior to SL 8.0 when the START variables were used. See [[SUSE_Package_Conventions/Init_Scripts#spc_is_installation Section 7.8, “Installation”] for more details. Do not forget to mention the utilities used in the PreReq tag. The macros %insserv_prereq and %fillup_prereq serve this purpose.

Options:

• -f skips the fillup part.
• -i skips the insserv part.
• -n defines that the parameter sysconfig_filename is used (see below).
• -p is ignored for backwards compatibility.
• -s defines that the parameter START_variable is used (see below).
• -y sets START variables to “yes” by default. It is ignored if X-UnitedLinux-Default-Enabled is specified in the init script.
• -Y forces setting the START variable to “yes”. This means the service is always activated regardless of the setting before an update.

Parameters:

• sysconfig_filename creates a pair with the option -n and defines the filename where the configuration is filled up, /etc/sysconfig/sysconfig_filename.

In addition, it defines a name of the file with templates. The macro searches for two possible template files. It prefers /var/adm/fillup-templates/sysconfig.sysconfig_filename.%name if it is available. Otherwise, it searches for /var/adm/fillup-templates/sysconfig.sysconfig_filename. The longer variant must be used if multiple packages write to the same config file. By default (the option -n is unused), the template is /var/adm/fillup-templates/sysconfig.%name and the target sysconfig file is /etc/sysconfig/%name.

• init_script_name defines a name of the init script processed by insserv. It must be defined if the option -i is not used. More init scripts names can be defined (see examples below).
• START_variable creates a pair with the option -s and redefines a name of the START variable, which is checked by an update. It also creates pairs with the parameter init_script_name. All pairs must be complete if the option -s is defined and multiple init scripts are processed at once (see examples below). See the notes of [[SUSE_Package_Conventions/Init_Scripts#spc_is_installation Section�7.8, “Installation”] to get more information about START variables.

By default (the option -s is unused), the name of the START variable is derived from the parameter init_script_name. In the concrete, the value of init_script_name is converted to uppercase and prefixed with START_ (see examples below).

Examples:

1. This example is taken from the package mailman (also shows the related part of the PreReq tag):

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

%post
%{fillup_and_insserv mailman}

It fills the configuration file /etc/sysconfig/mailman from the template /var/adm/fillup-templates/sysconfig.mailman. It runs insserv on /etc/init.d/mailman by checking the variable START_MAILMAN.

1. This example is taken from the package hwinfo (also shows the related part of the PreReq tag):

PreReq:       ... %insserv_prereq

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

It runs insserv on /etc/init.d/hwscan and enables the service by default. See that only the insserv part is in PreReq because the fillup part is omitted with the option -f.

1. This example is taken from the package openssh:

%{fillup_and_insserv -n -y ssh sshd}

It fills the configuration file /etc/sysconfig/ssh. The template is taken either from /var/adm/fillup-templates/sysconfig.ssh.openssh or from /var/adm/fillup-templates/sysconfig.ssh. The first one is preferred. It runs insserv on /etc/init.d/sshd by checking the variable START_SSHD. It enables the service by default.

1. This example is taken from the package apache:

%{fillup_and_insserv -s apache START_HTTPD}

It fills the configuration file /etc/sysconfig/apache from the template /var/adm/fillup-templates/sysconfig.apache. It runs insserv on /etc/init.d/apache by checking the variable START_HTTPD.

1. This example is taken from the package openldap2:

%{fillup_and_insserv -n openldap ldap slurpd}

It fills the configuration file /etc/sysconfig/openldap. The template is taken either from /var/adm/fillup-templates/sysconfig.openldap.openldap2 or from /var/adm/fillup-templates/sysconfig.openldap. The first one is preferred. It runs insserv on /etc/init.d/ldap by checking the variable START_LDAP. It runs insserv on /etc/init.d/slurpd by checking the variable START_SLURPD.

1. This example shows an usage of the option -s for more init scripts:

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

It does the same things as the command in the previous example. The only difference is that the START variables are explicitly named here.

3.7. %fillup_only

This macro can be used to fill up sysconfig files.

Synopsis:

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

The macro %fillup_only is used to insert (fill up) the variables from a template /var/adm/fillup-templates/sysconfig.sysconfig_filename[-suffix] into a config file /etc/sysconfig/sysconfig_filename. The base function is similar to %fillup_and_insserv -i but it allows modifying config file in subdirectories of /etc/sysconfig.

The macro is typically used in the %post script. Do not forget to mention the utilities used in the PreReq tag. There is the macro %fillup_prereq for this purpose.

Options:

• -a uses the package name as a suffix of the syconfig template filename.
• -d defines that the parameter sysconf_subdir is used (see below).
• -n defines that the parameter sysconfig_filename is used (see below).
• -s defines that the parameter suffix is used (see below).

Parameters:

• sysconfig_filename creates a pair with the option -n and defines a name of the sysconfig file and a name of the file with templates.

By default (the option -n is unused), the package name is used instead. So, the template /var/adm/fillup-templates/sysconfig.%name is filled up to /etc/sysconfig/%name.

• sysconfig_template_filename_suffix creates a pair with the option -s and defines a suffix of the filename with templates.
• sysconfig_subdir creates a pair with the option -d and defines a subdirectory of /etc/sysconfig where the synconfig file is located.

Examples:

1. This example is taken from the package tetex (also shows the related part of the PreReq tag):

PreReq:       %fillup_prereq ...

%post
%{fillup_only}

It fills up the config file /etc/sysconfig/tetex from the template /var/adm/fillup-templates/sysconfig.tetex.

1. This example is from the package man:

%{fillup_only -an cron}

It fills the config file /etc/sysconfig/cron from the template /var/adm/fillup-templates/sysconfig.cron-man.

1. This example is taken from the package dhcp:

%{fillup_only -ans syslog dhcpd}

It fills the config file /etc/sysconfig/syslog from the template /var/adm/fillup-templates/sysconfig.syslog-dhcpd.

1. This example is taken from the package samba:

%fillup_only -nsd dhcp samba-client network

It fills the config file /etc/sysconfig/network/dhcp from the template /var/adm/fillup-templates/sysconfig.dhcp-samba-client.

3.8. %find_lang

This macro helps to mark locale-dependent files with the respective %lang tag in the file list.

Synopsis:

%find_lang name [filelist]

The macro %find_lang searches the directories /usr/share/locale and locale/*/LC_MESSAGES for name.mo files. It also searches gnome/help/name and kde*/share/doc/HTML/*/name directories for a localized documentation. Then it creates the file filelist where the files are marked by the respective %lang(locale) tag and also by the %doc tag. Such a file list can be then passed to the %files tag via -f option. See below for an example.

It is recommended to use this macro only if the BuildRoot tag is defined as otherwise the entire system will be searched.

Parameters:

name defines the name of .mo files and the name of subdirectories where GNOME and KDE localized documentation is stored. It is also used for the filename where the generated file list is stored if the parameter filelist is not defined.

filelist defines the name of the file where the generated list of files is stored. name.lang is used if not defined.

This example is taken from the package 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

This macro is used to clean up when insserv after a package is removed. Each package providing an init script should call this macro in %postun script.

This example is taken from the package openldap2:

%postun
%restart_on_update ldap slurpd
%insserv_cleanup

3.10. %insserv_force_if_yast

This macro is a plain call of the utility insserv if the package is not installed by YaST. When YaST is used, it calls insserv -f. This helps to avoid errors on "out-of-sequence" package installations.

The macro is used in %post script of packages that install an init script and wants to enable it by default. It is also used if the init script existed prior to SL 8.0 when the START variables were used. See [[SUSE_Package_Conventions/Init_Scripts#spc_is_installation Section�7.8, “Installation”] for more details. Do not forget to mention the used utilities in the PreReq tag. There are the macros %insserv_prereq and %fillup_prereq for this purpose.

This example is from the package glibc, subpackage nscd (shows also the related PreReq tag):

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

%post -n nscd
%{insserv_force_if_yast nscd}

3.11. %install_info

This macro updates dir entries for info files.

Synopsis:

%install_info install_info_options

The macro %install_info runs bin/install-info with some additional tests. It accepts any option from the install-info utility. See man install-info for more details.

Each package providing info pages should call this macro in %post script. Do not forget to mention all the used utilities in the PreReq tag. There is the macro %install_info_prereq for this purpose.

Examples:

1. This example is taken from the package zsh (shows also the related PreReq tag):

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

1. This example is taken from the package rplay (a package with multiple info pages). The example also shows the related 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

This macro removes dir entries for info files.

Synopsis:

%install_info_delete install_info_options

The macro %install_info_delete is a complement to the macro %install_info. It runs sbin/install-info --quiet –delete with some additional tests. It accepts any option from the install-info utility. See man install-info for more details.

Each package providing info pages should call this macro in %postun script. Do not forget to mention all the utilities used in the PreReq tag. The macro %install_info_prereq is intended for this purpose.

Examples:

1. This example is taken from the package zsh (also shows the related PreReq tag):

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

1. This example is taken from the package rplay (a package with multiple info pages). The example also shows the related 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

This macro is substituted by the path where architecture-specific parts of Perl are installed, for example, /usr/lib/perl5/5.8.5/i586-linux-thread-multi.

It is normally only used by the perl package itself and by the macro %perl_process_packlist. See below.

3.14. %perl_make_install

This macro does the make install call correctly on various products. Before SL 9.0, the normal way to invoke it was:

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

For 9.0 and later versions:

make DESTDIR=$RPM_BUILD_ROOT install_vendor

With the macro %perl_make_install, this is done correctly according to the version.

This example comes from the package perl-URI:

%install
%perl_make_install

3.15. %perl_process_packlist

This macro prepares some files, related to perl modules, for the final package. It does the following actions:

• Removes $RPM_BUILD_ROOT from %perl_archlib/perllocal.pod and renames the file to a package-specific file. See below for more details.
• Searches for the installed .packlist files and removes $RPM_BUILD_ROOT from them.

Each package including a perl module should call this macro in the section %install.

The file %perl_archlib/perllocal.pod must be renamed because it contains information about additional installed perl modules and evidently cannot be installed at the same place from multiple packages. Therefore, it is renamed and a special SuSEconfig module, /sbin/conf.d/SuSEconfig.perl, adds this information to the system %perl_archlib/perllocal.pod after the package is installed.

This example is taken from the package perl_URI:

%install
%perl_make_install
%perl_process_packlist

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

3.16. %perl_sitearch

This macro is substituted by the path where architecture-specific parts of Perl modules are installed by a local administrator (/usr/lib/perl5/site_perl/5.8.5/i586-linux-thread-multi). The packages distributed within SUSE Linux use the path defined by %perl_vendorarch instead. See below.

3.17. %perl_sitelib

This macro is substituted by the path where architecture-independent parts of Perl modules are installed by a local administrator (/usr/lib/perl5/site_perl/5.8.5). The packages distributed within SUSE Linux use the path defined by %perl_vendorlib instead (see below).

3.18. %perl_vendoarch

This macro is substituted by the path where architecture-specific parts of Perl modules are installed by a Linux vendor (/usr/lib/perl5/vendor_perl/5.8.5/i586-linux-thread-multi). The macro is typically used in the file list. This example comes from the package perl-URI:

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

This path has been used since SL 9.0. Until then, the Perl modules were installed below /usr/lib/perl5/site_perl using the macro %perl_sitearch. The directory site_perl is now intended for modules installed by a local administrator (see above at %perl_sitearch).

3.19. %perl_vendorlib

This macro substitutes for the path where architecture-independent parts of Perl modules are installed by a Linux vendor (/usr/lib/perl5/vendor_perl/5.8.5). The macro is typically used in the file list. This example comes from the package perl-URI:

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

This path has been used since SL 9.0. Until then, the Perl modules were installed below /usr/lib/perl5/site_perl using the macro %perl_sitearch. The directory site_perl is now intended for modules installed by a local administrator (see above at %perl_sitelib).

3.20. %perl_version

This macro is substituted by the version of Perl used for building the package, such as 5.8.5. It is used in packages providing a perl module to define the dependency on Perl.

It is typically used the following way. This example is taken from the package perl-URI:

Requires:     perl = %{perl_version}

3.21. %py_incdir

This macro substituted by the path where Python header files are installed, such as /usr/include/python2.3. See [[SUSE_Package_Conventions/Specific_Packages#spc_sp_python_modules Section�10.4, “Python Modules”] for an example.

3.22. %py_libdir

This macro is substituted by the path where Python modules are installed, such as /usr/lib/python2.3. See [[SUSE_Package_Conventions/Specific_Packages#spc_sp_python_modules Section 10.4, “Python Modules”] for an example.

3.23. %py_requires

This macro is substituted by PreReq and BuildRequires tags. This defines dependency on the same python major version as is used during build. See [[SUSE_Package_Conventions/Specific_Packages#spc_sp_python_modules Section 10.4, “Python Modules”] for an example.

3.24. %py_sitedir

This macro is substituted by the path where all extra Python modules all installed, such as /usr/lib/python2.3/site-packages. See [[SUSE_Package_Conventions/Specific_Packages#spc_sp_python_modules Section 10.4, “Python Modules”] for an example.

3.25. %py_ver

This macro is substituted by the Python major version, such as 2.3. See [[SUSE_Package_Conventions/Specific_Packages#spc_sp_python_modules Section 10.4, “Python Modules”] for an example.

3.26. %remove_and_set

This macro is used to remove obsolete sysconfig variables.

Synopsis:

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

The macro %remove_and_set removes variables from /etc/rc.config and /etc/sysconfig/sysconfig_filename and sets them in the actual environment for further handling. If a variable is not found, it is set to "no" by default or it is set to “yes” if the option -y is used.

Options:

• -n defines that the parameter sysconfig_filename is used (see below).
• -y sets the default value to “yes”.

Parameters:

• sysconfig_filename creates a pair with the option -n and defines the syconfig filename. The package name (%name) is used as the sysconfig filename otherwise.
• variable defines the name of a variable to remove. Multiple variables can be defined.

Examples:

1. This example is taken from the package 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}

This code sets the variable POSTFIX_NULLCLIENT from etc/sysconfig/postfix to the value of the obsolete variable NULLCLIENT from etc/sysconfig/mail. Then the obsolete variable is removed.

1. This example is taken from the package 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

The obsolete variables USE_NIS_FOR_AUTOFS, USE_NISPLUS_FOR_AUTOFS are removed from /etc/rc_config and /etc/sysconfig/autofs and the removed values are used to modify an actual configuration. The detected values cannot be used in the previous example because the macro %remove_and_set is able to set only values “yes” or “no” in the environment.

3.27. %restart_on_update

This macro restarts a service after an update.

Synopsis:

%restart_on_update service...

The macro %restart_on_update runs /etc/init.d/service try-restart if not running under YaST in the instsys mode. Multiple services can be defined.

This macro is usually used in the %postun script of packages providing a service. However, it cannot be used if it cannot be guaranteed that the service will work after an update.

Examples:

1. This example is taken from the package rsync:

%postun
%restart_on_update rsyncd
%insserv_cleanup

1. This example is taken from the package samba (restarts two services):

%postun
%restart_on_update nmb smb
%insserv_cleanup

3.28. %run_ldconfig (deprecated)

This macro runs ldconfig if not running from YaST. YaST runs ldconfig itself after all selected packages are installed.

It was used in both %post and %postun scripts of packages providing a library. The macro is deprecated and should not be used now. Instead, /sbin/ldconfig should be called directly both scripts, even from YaST, to keep from breaking other %post scripts. It could be done the following way:

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

If ldconfig is not the only command, the -p option is not usable. For example, the %post script could look like:

%post
/sbin/ldconfig
[...]

3.29. %run_permissions

This script fixes permissions of problematic files to follow a system security setting. It requires the package permissions to be installed.

It should be called in the %post script of packages installing a file that has secure permissions defined in /etc/permissions.{easy,secure} or in /etc/permissions.d/%name.{easy,secure}. Do not forget to mention the package permissions in the PreReq tag.

It is usually used together with the macro %verify_permissions.

This example is taken from the package xtetris (also shows the related PreReq tag):

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

3.30. %sles_version

This macro expands to the version of SLES where the package is built. It is ”7” for SLES7, ”8” for SLES8, etc. It is ”0” when not building on SLES.

See also %suse_version and %ul_version.

This example is taken from the package 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

This macro stops a service after a package is removed.

Synopsis:

%stop_on_removal service...

The macro %stop_on_removal runs /etc/init.d/service stop if not running from YaST in the instsys mode. Multiple services can be defined.

Each package providing a service that can be stopped should call this macro on all services in the %preun script.

Examples:

1. This example is taken from the package rsync:

%preun
%stop_on_removal rsyncd

1. This example is taken from the package samba (stops two services):

%preun
%stop_on_removal smb nmb

3.32. %suse_update_config

This macro updates some auto-stuff related files.

Usage:

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

This macro takes the following actions for the current directory and all directories given as parameters:

• config.guess and config.sub are overwritten by their most current versions from /usr/share/automake*/.
• depcomp and missing are added if not present in the processed directory but present in /usr/share/automake*/.
• ltconfig and ltmain.sh are patched to accept both linux-gnu and linux.
• /lib is replaced by /%_lib in some occurrences in both ltconfig and ltmain.sh.

This macro should be called in all packages using the problematic files. However, it is not needed when autoreconf or aclocal, libtoolize, automake, and autoconf is used, because they are able to update the needed things.

This macro should be tested for existence when used in the section %prep. This allows running this section on other distributions where the macro is not available. See the examples below.

Options:

• -c — do not update config.guess, config.sub, depcomp and missing
• -f — force, ignore time stamps
• -l — do not update ltconfig and ltmain.sh

Parameters:

• dir defines an additional directory where the files should be updated. Multiple directories can be defined.

Examples:

1. This example is taken from the package 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

1. This example is taken from the package xosview (updates files in both ./ and ./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

3.33. %suse_update_desktop_file

This macro updates .desktop files.

Synopsis:

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

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

The macro %suse_update_desktop_file updates translations, adds categories (needed to sort menus), and does some sanity checks in the given .desktop file. It requires the package update-desktop-files.

Each package providing a .desktop file should call this macro for all the .desktop files in the section %install. Do not forget to mention the package update-desktop-files in the SUSE_Package_Conventions#spc_ps_buildrequires_tag BuildRequires tag. It is included in the meta packages:

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

The package update-desktop-files need not be explicitly mentioned in the BuildRequires tag if any of these meta packages is already there.

Options:

• -c filename name comment exec icon [category] — Create a new .desktop file initialized by the parameters filename, name, comment, exec, icon, and category the following way:

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

and install it as $RPM_BUILD_ROOT/usr/share/applications/filename.desktop.

• -i — Search $RPM_SOURCE_DIR and /usr/share/update-desktop-files/templates for the template filename.desktop and install it as $RPM_BUILD_ROOT/usr/share/applications/filename.desktop.
• -n — Do not update translations. It is useful if the lines Name= and GenericName= contain a string that cannot be translated.
• -r — Replace categories defined in the .desktop file with the new one defined by the parameter category. By default, the new categories are only added after the already included categories.
• -u — Add the line X-SuSE-Unimportant=true to the .desktop file.
• -Ddocpath Sets the .desktop file DocPath entry.
• -Nname Sets the .desktop file Name entry.
• -Ggenericname Sets the .desktop file GenericName entry.

Parameters:

• filename defines a filename of the .desktop file. The value is the filename without the suffix .desktop.
• category is used to add or modify the line Categories= in the .desktop file. This line is used to sort entries into submenus.

Examples:

1. This example is taken from the package kvim (also shows the related parts of BuildRequires tag and %files section):

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

%install
[...]
%suse_update_desktop_file KVim TextEditor

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

This code updates translations in the already installed /opt/kde3/share/applnk/Editors/KVim.desktop. As the original .desktop file does not contain the line Categories=, it is initialized to Categories=TextEditor;.

1. This example is from the package crack-atack: (also shows the related parts of BuildRequires tag, Source tags and %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

This code finds the two templates in $RPM_SOURCE_DIR and installs them into /usr/share/applications. See the section %files for the final path. It also updates translations. As the templates do not contain the line Categories=, it is initialized to Categories=Game;ArcadeGame;.

1. This example is taken from the package 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

This code updates translations in the already installed desktop files. In addition, for example, Kthesaurus.desktop is marked as unimportant and the obsolete line Categories= is replaced with Categories=VectorGraphics; in karbon.dekstop.

1. This example is taken from the package qbrew:

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

1. This code creates a .desktop file:

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

Then it adds available translations and installs it as /usr/share/applications/qbrew.desktop.

3.34. %suse_version

This macro expands to the version of SUSE Linux the package is built in. It is ”800” for SUSE Linux 8.0, ”810” for 8.1, etc.

See also %sles_version and %ul_version.

This example it taken from the package binutils:

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

3.35. %tcl_version

This macro expands to the version of Tcl used on the product where the package is built. It is "8.3" for tcl-8.3, “8.4” for tcl-8.4, etc.

This example is taken from the package 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

This macro expands to a version of United Linux where the package is built. It is “1” for UL 1.0 and “0” when not building on UL.

See also %sles_version and %suse_version.

This example is taken from the package 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

This macro helps to verify permissions of files if they depend on the system security setting.

Usage:

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

Each package, including files that have different permissions defined in /etc/permissions or /etc/permissions.easy than in /etc/permissions.secure, should call this macro in the %verifyscript section.

It is usually used together with the macro SUSE_Package_Conventions/RPM_Macros#spc_rm_run_permissions %run_permissions. The problematic files are usually marked as %verify(not mode) in the package filelist (see examples below).

Options:

• -f filelist — Defines a file with a list of files to check.
• -e file — defines a file to check.

Both options can be repeated.

Examples:

1. This example is taken from the package xtetris (also shows the part with %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

1. This example is taken from the package 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

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