Installation scripts: Running scripts during package install and/or removal

Packaging system such as .ipkg and .deb support pre and post installation and pre and post removal scripts which are run during package install and/or package removal on the target system.

These scripts can be defined in your recipes to enable actions to be performed at the appropriate time. Common uses include starting new daemons on installation, stopping daemons during uninstall, creating new user and/or group entries during install, registering and unregistering alternative implementations of commands and registering the need for volatiles.

The following scripts are supported:

preinst

The preinst script is run prior to installing the contents of the package. During preinst the contents of the package are not available to be used as part of the script. The preinst scripts are not commonly used.

postinst

The postinst script is run after the installation of the package has completed. During postinst the contents of the package are available to be used. This is often used for the creation of volatile directories, registration of daemons, starting of daemons and fixing up of SUID binaries.

prerm

The prerm is run prior to the removal of the contents of a package. During prerm the contents of the package are still available for use by the script. The prerm scripts

postrm

The postrm script is run after the completion of the removal of the contents of a package. During postrm the contents of the package no longer exist and therefore are not available for use by the script. Postrm is most commonly used for update alternatives (to tell the alternatives system that this alternative is not available and another should be selected).

Scripts are registered by defining a function for:

The following example from ndisc6 shows postinst scripts being registered for three of the packages that ndisc6 creates:

# Enable SUID bit for applications that need it
pkg_postinst_${PN}-rltraceroute6 () {
    chmod 4555 ${bindir}/rltraceroute6
}
pkg_postinst_${PN}-ndisc6 () {
    chmod 4555 ${bindir}/ndisc6
}
pkg_postinst_${PN}-rdisc6 () {
    chmod 4555 ${bindir}/rdisc6
}

Note

These scripts will be run via /bin/sh on the target device, which is typically the busybox sh but could also be bash or some other sh compatible shell. As always you should not use any bash extensions in your scripts and stick to basic sh syntax.

Note that several classes will also register scripts, and that any script you declare will have the script for the classes append to by these classes. The following classes all generate additional script contents:

update-rc.d

This class is used by daemons to register there init scripts with the init code.

Details are provided in the initscripts section.

module

This class is used by linux kernel modules. It's responsible for calling depmod and update-modules during kernel module installation and removal.

kernel

This class is used by the linux kernel itself. There is a lot of housekeeping required both when installing and removing a kernel and this class is responsible for generating the required scripts.

qpf

This class is used when installing and/or removing qpf fonts. It register scripts to update the font paths and font cache information to ensure that the font information is kept up to date as fonts and installed and removed.

update-alternatives

This class is used by packages that contain binaries which may also be available for other packages. It tells that system that another alternative is available for consideration. The alternatives system will create a symlink to the correct alternative from one or more available on the system.

Details are provided in the alternatives section.

gtk-icon-cache

This class is used by packages that add new gtk icons. It's responsible for updating the icon cache when packages are installed and removed.

gconf

package

The base class used by packaging classes such as those for .ipkg and .deb. The package class may create scripts used to update the dynamic linkers ld cache.

The following example from p3scan shows and postinst script which ensure that the required user and group entries exist, and registers the need for volatiles (directories and/or files under /var). In addition to explicitly declaring a postinst script it uses the update-rc.d class which will result in an additional entry being added to the postinst script to register the init scripts and start the daemon (via call to update-rc.d as describes in the alternatives section).

inherit autotools update-rc.d

...

# Add havp's user and groups
pkg_postinst_${PN} () {
        grep -q mail: /etc/group || addgroup --system havp
        grep -q mail: /etc/passwd || \
            adduser --disabled-password --home=${localstatedir}/mail --system \
                    --ingroup mail --no-create-home -g "Mail" mail
        /etc/init.d/populate-volatile.sh update
}

Several scripts in existing recipes will be of the following form:

if [ x"$D" = "x" ]; then
    ...
fi

This is testing if the installation directory, D, is defined and if it is no actions are performed. The installation directory will not be defined under normal circumstances. The primary use of this test is to permit the application to be installed during root filesystem generation. In that situation the scripts cannot be run since the root filesystem is generated on the host system and not on the target. Any required script actions would need to be performed via an alternative method if the package is to be installed in the initial root filesystem (such as including any required users and groups in the default passwd and group files for example.)