The %pretrans Scriptlet¶

Note that the %pretrans scriptlet will, in the particular case of system installation, run before anything at all has been installed. This implies that it cannot have any dependencies at all. For this reason, %pretrans is best avoided, but if used it MUST (by necessity) be written in Lua. See http://rpm.org/user_doc/lua.html for more information.

Saving state between scriptlets¶

Sometimes a scriptlet needs to save some state from an earlier running scriptlet in order to use it at a later running scriptlet. This is especially common when trying to optimize the scriptlets. Examples:

• If a %posttrans needs to de-register some piece of information when upgrading but the file that has that information is removed when the old package is removed the scriptlets need to save that file during %pre or %post so that the script in %posttrans can access it.
• If we only want the program in %posttrans to do its work once per-transaction, we may need to write out a flag file so that the %posttrans knows whether to perform an action.

To address these issues scriptlets that run earlier need to write out information that is used in %posttrans. We recommend using a subdirectory of %{_localstatedir}/lib/rpm-state/ for that. For instance, the eclipse plugin scripts touch a file in %{_localstatedir}/lib/rpm-state/eclipse/ when they’re installed. The %posttrans runs a script that checks if that file exists. If it does, it performs its action and then deletes the file. That way the script only performs its action once per transaction.

Macros¶

If RPM file triggers are not appropriate, complex scriptlets which are shared between multiple packages MAY be placed in RPM macros. This has two benefits:

• The standard package authors only have to remember the macros, not the complex stuff that it does
• The macros’ implementations may change without having to update the package

When writing the macros, the FPC will still want to review the macros (and perhaps include the implementation of the macros in the guideline to show packagers what’s happening behind the scenes).

One principle that the FPC follows is that macros generally don’t contain the start of scriptlet tags (for instance, %pre) because this makes it difficult to do additional work in the scriptlet. This also means that a single macro can not be defined to do things in both %pre and %post. Instead, write one macro that performs the actions in %pre and a separate macro that performs the actions in %post. This principle makes it so that all spec files can use your macros in the same manner even if they already have a %pre or %post defined.

Of course, in the above situation it is better to use RPM file triggers if at all possible.

Shared libraries¶

Installing shared libraries requires running /sbin/ldconfig to update the dynamic linker’s cache files. These can be invoked like:

%post
/sbin/ldconfig
%postun
/sbin/ldconfig

It is also common to invoke these with the ‘-p’ option as they are often the only program invoked in a scriptlet:

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

If applicable, the latter way is recommended because doing so will automatically add appropriate dependencies on /sbin/ldconfig to the package (and FWIW, will prevent unnecessarily launching a shell process in the scriptlets).

Users and groups¶

These are discussed on a separate page

Services¶

GConf¶

GConf is a configuration scheme currently used by the GNOME desktop. Programs which use it setup default values in a [NAME] .schemas file which is installed under %{_sysconfdir}/gconf/schemas/[NAME] .schemas. These defaults are then registered with the gconf daemon which monitors the configuration values and alerts applications when values the applications are interested in change. The schema files also provide documentation about what each value in the configuration system means (which gets displayed when you browse the database in the gconf-editor program).

For packaging purposes, we have to disable schema installation during build, and also register the values in the [NAME] .schemas file with the gconf daemon on installation and unregister them on removal. Due to the ordering of the scriptlets, this is a four step process.

Disabling the GConf installation during the package creation can be done like so:

%install
export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1
make install DESTDIR=$RPM_BUILD_ROOT
...

The GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL environment variable suppresses the installation of the schema during the building of the package. An alternative for some packages is to pass a configure flag:

%build
%configure --disable-schemas
...

Unfortunately, this configure switch only works if the upstream packager has adapted their Makefile.am to handle it. If the Makefile.am is not configured, this switch won’t do anything and you’ll need to use the environment variable instead.

Here’s the second part:

BuildRequires: GConf2
Requires(pre): GConf2
Requires(post): GConf2
Requires(preun): GConf2
...
%pre
%gconf_schema_prepare schema1 schema2
%gconf_schema_obsolete schema3

In this section we uninstall old schemas during upgrade using one of two macros.

%gconf_schema_prepare is used for any current GConf schemas. It takes care of uninstalling previous versions of schemas that this package currently installs. It takes a space separated list of schema names without path or suffix that the package installs. Note that behind the scenes, this macro works with the %post scriptlet to only process GConf schemas if changes have occurred.

%gconf_schema_obsolete is used for schemas that this package previously provided but no longer does. It will deregister the old schema if it is present on the system. Nothing will happen if the old schema is not present. This macro takes a space separated list of schemas to uninstall. One example of using this might be if the package changed names. If the old schema was named foo.schemas and the new schema is named foobar.schemas you’d use:

%gconf_schema_prepare foobar
%gconf_schema_obsolete foo

The next section does the processing of the newly installed schemas:

%post
%gconf_schema_upgrade schema1 schema2

%gconf_schema_upgrade takes a space separated list of schemas that the package currently installs just like %gconf_schema_prepare. Behind the scenes, it does the actual work of registering the new version of the schema and deregistering the old version.

The last section is for unregistering schemas when a package is removed:

%preun
%gconf_schema_remove schema1 schema2

When a package is upgraded rpm invokes the %pre scriptlet to register and deregister the schemas. When a package is uninstalled, the %preun scriptlet is used. %gconf_schema_remove takes the list of schemas that this package currently provides and removes them for us.

repoquery --whatprovides "/etc/gconf/schemas/*" |sort |uniq |wc -l

Texinfo¶

The GNU project and many other programs use the texinfo file format for much of its documentation. These info files are usually located in /usr/share/info/. When installing or removing a package, install-info from the info package takes care of adding the newly installed files to the main info index and removing them again on deinstallation.

Requires(post): info
Requires(preun): info
...
%post
/sbin/install-info %{_infodir}/%{name}.info %{_infodir}/dir || :

%preun
if [ $1 = 0 ] ; then
  /sbin/install-info --delete %{_infodir}/%{name}.info %{_infodir}/dir || :
fi

These two scriptlets tell install-info to add entries for the info pages to the main index file on installation and remove them at erase time. The “|| :” in this case prevents failures that would typically affect systems that have been configured not to install any %doc files, or have read-only mounted, %_netsharedpath /usr/share.

Icon Cache¶

If an application installs icons into one of the subdirectories in %{_datadir}/icons/ (such as hicolor in the following examples), icon caches must be updated so that the installed icons show up in menus right after package installation. This consists of updating the timestamp of the top-level icon directory where the icons were installed, and running gtk-update-icon-cache. ‘touch’ing the top-level dir is done so that environments compatible with the Icon theme specification can refresh their caches, and gtk-update-icon-cache which is additionally required for GNOME also does its work based on the dir timestamp.

Note that no dependencies should be added for this. If gtk-update-icon-cache is not available, there’s nothing that would be needing the cache update, ditto if “touch” is not available, there’s nothing that would benefit from icon cache updates installed yet either. Not adding the dependency on gtk-update-icon-cache (ie. gtk2 >= 2.6.0) or “touch” makes it easier to use the package (or the same specfile) on systems where it’s not available nor needed, such as older distro versions or (very) trimmed down installations, and generally results in less entries in specfiles, rpmdb, and repo metadatas.

%post
/bin/touch --no-create %{_datadir}/icons/hicolor &>/dev/null || :

%postun
if [ $1 -eq 0 ] ; then
    /bin/touch --no-create %{_datadir}/icons/hicolor &>/dev/null
    /usr/bin/gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :
fi

%posttrans
/usr/bin/gtk-update-icon-cache %{_datadir}/icons/hicolor &>/dev/null || :

Systemd¶

Packages containing systemd unit files need to use scriptlets to ensure proper handling of those services. Services can either be enabled or disabled by default. To determine which case your specific service falls into, please refer to FESCo’s policy here: Packaging:DefaultServices. On upgrade, a package may only restart a service if it is running; it may not start it if it is off. Also, the service may not enable itself if it is currently disabled.

%{?systemd_requires}
BuildRequires: systemd

[...]
%post
%systemd_post apache-httpd.service

%preun
%systemd_preun apache-httpd.service

%postun
%systemd_postun_with_restart apache-httpd.service

%postun
%systemd_postun apache-httpd.service

%{?systemd_requires}
BuildRequires: systemd

[...]
%post
%systemd_user_post %{name}.service

%preun
%systemd_user_preun %{name}.service

Shells¶

/etc/shells is a text file which controls whether an application can be used as a system login shell of users. It contains the set of valid shells which can be used in the system. If you are packaging a new shell, you need to add entries to this file that reference the added shells. See: man 5 SHELLS for more information.

As this file can be edited by sysadmins, we need to first determine if relevant lines are already in the file. If they don’t already exist then we just need to echo the shell’s binary path to the file. Since the UsrMove Feature in Fedora 17 made /bin a symlink to /usr/bin we need to place both paths into the /etc/shells file. Here is an example of the scriptlet to package with shell named “foo”:

%post
if [ "$1" = 1 ]; then
  if [ ! -f %{_sysconfdir}/shells ] ; then
    echo "%{_bindir}/foo" > %{_sysconfdir}/shells
    echo "/bin/foo" >> %{_sysconfdir}/shells
  else
    grep -q "^%{_bindir}/foo$" %{_sysconfdir}/shells || echo "%{_bindir}/foo" >> %{_sysconfdir}/shells
    grep -q "^/bin/foo$" %{_sysconfdir}/shells || echo "/bin/foo" >> %{_sysconfdir}/shells
fi

%postun
if [ "$1" = 0 ] && [ -f %{_sysconfdir}/shells ] ; then
  sed -i '\!^%{_bindir}/foo$!d' %{_sysconfdir}/shells
  sed -i '\!^/bin/foo$!d' %{_sysconfdir}/shells
fi