A
specfile
gives optional scripts that are automatically executed when the
package is installed or uninstalled.
Up to five scripts may be specified:
%pre [ -p interpreter ] [name]This script gets executed just before the package's files are installed.
%post [ -p interpreter ] [name]This script gets executed just after the package's files are installed.
%preun [ -r ] [ -p interpreter ] [name]This script gets executed just before the package's files are uninstalled (whenever the package gets removed, eventually).
-r specifies that this package's required resources must
be present when running this script.
See Section 9, “Special requirements of uninstallation scripts and triggers” for more information.
%postun [ -r ] [ -p interpreter ] [name]This script gets executed just after the package's files are uninstalled (whenever the package gets removed, eventually).
-r specifies that this package's required resources must
be present when running this script.
See Section 9, “Special requirements of uninstallation scripts and triggers” for more information.
%verify [ -p interpreter ] [name]
This script gets executed by lpm's --verify
option.
This is a custom script that a package can have, which can
do whatever extra
work is needed to verify the package's integrity, in addition to
--verify's basic file comparison checks.
%script [ -p interpreter ] [name]
Specifies the main script in a dedicated script package.
A script package is a special package that contains a single script,
introduced by a %script.
See Section 10, “Script packages” for more information.
The main package, and each subpackage, have their own install/uninstall
scripts.
Specify the subpackage's name after
%pre,
%post,
%preun,
%postun,
or %verify;
otherwise the script goes with the main package.
The script normally gets executed by the system's default shell interpreter
(usually /bin/bash).
A non-default shell interpreter may be specified by prepending the optional
“-p pathname” parameter.
pathname must naturally be an absolute pathname.
LPMtool uses the a “hash-bang” to run the interpreter. LPMtool prepends the hash-bang to the script, and executes it:
#! pathname
[ ... script ... ]
LPMtool reserves the right to place additional hash comment directives in lines immediately after the first line, for its own internal reasons. This is normally of no concern with regular shell scripts, and even Perl scripts. However, this factoid should be kept in mind when using other, non-standard script interpreters.
The
%pre,
%post,
%preun, or
%postun script, when invoked,
receives one parameter (which is accessible
as $1 when using the default /bin/bash
interpreter): a count of how many versions of the package (or subpackage)
will remain installed after the current package is installed, or uninstalled.
For example, when installing a new package “ultragizmo”,
the %pre and %post scripts receive
the argument of “1”, because after the installation completes
there will be only one version of UltraGizmo installed (there were none
before).
When the UltraGizmo package is uninstalled later,
its %post and %postun
scripts get the
argument of “0”.
This indicates that no version of the
“ultragizmo” package will remain afterwards.
As used in this chapter, “version” is used in its liberal meaning as any copy of a package with the same name (and architecture). Recall that each LPMtool package carries a separate version and release number, and LPMtool permits the installation of two packages with the same version, but a different release number.
For the purpose of computing the version count, they will be considered as two versions of the package. This also applies to triggers, described in the next section.
Updating an older version of the package involves two steps: the new version of the package gets installed; the old version of the package gets removed. Therefore, the following steps occur when updating an older version of the “ultragizmo” package to a newer one:
The new version's %pre
script gets invoked with the argument of
“2”.
The new version's files are installed.
The new version's %post
script gets invoked with the argument of
“2”.
At this point in time two versions of the “ultragizmo” package are installed, the old version and the new version. That's why the argument to those scripts was “2”. Although this is just a temporary situation, the argument to the preceding script was “2” because there will technically be two versions of UltraGizmo when the installation process finishes.
The old version's %preun
script gets invoked with the argument of
“1”.
The old version's files are removed.
The old version's %postun
script gets invoked with the argument of
“1”.
The system is now left with one version of the UltraGizmo package, the new version. This explains the “1” argument to the uninstall scripts.
This is what normally occurs for the great overwhelming majority of packages that typically have only one version installed at a time. Certain, specialty packages, may have multiple versions installed at the same time. The argument to the package's install/uninstall script is obtained in the same manner: by computing how many versions of these package will exist at the conclusion of the current install/uninstall operation.
Packages with the same name, but built for different architectures, are considered as distinct packages for the purposes of computing the the package count passed as an argument to the scripts. When installing or uninstalling a package, other packages with the same name, but a different architecture, are not counted.
Triggers are scripts that are very similar to
%pre,
%post,
%preun,
%postun, and
%verify.
Each package and subpackage may define their own triggers.
Triggers are not invoked when the package, or the subpackage, gets installed
or uninstalled, but they are invoked in response to some other
package or subpackage's installation or uninstallation.
Triggers enable a package to do something when some other package gets installed or uninstalled. LPMtool's triggers are modeled after RPM's triggers, but due to minimal documentation their behavior might subtly differ from RPM's. LPMtool's triggers are implemented as follows:
%triggerin [ -p interpreter ] -- resources
Run the following script using interpreter
(defaults to the system's shell interpreter) when
resources are installed.
resources specifies one or more comma-separated
resources.
These resources are nearly always names of packages; but they may also be
other kinds of resources LPMtool understands,
such as shared libraries and Perl modules.
When a new package is installed, if its triggers'
resources those are already installed, those
triggers will be immediately executed.
Then, if the new package contains any resources wanted by triggers in
a package that's already installed, those triggers will also be executed.
All triggers get executed after the new package's files are installed.
%triggerun [ -r ] [ -p interpreter ] -- resources
Run this trigger when
resources are uninstalled.
When a package is uninstalled, if the package has triggers that match
resources provided by other, installed packages,
those
triggers will be executed.
Then, if other packages have any triggers whose resources match the
provided resources of the package about to be
uninstalled, those triggers will also be executed.
All triggers get executed before the package's files are deleted.
-r specifies that the triggering package's required resources
must be present when running the trigger script.
See Section 9, “Special requirements of uninstallation scripts and triggers” for more information.
%triggerpostun [-r] [ -p interpreter ] -- resources
This trigger is similar to %triggerpostun except that
the trigger script runs after the package's files are deleted.
A package may have both %triggerun and
%triggerpostun triggers.
-r specifies that the triggering package's required resources
must be present when running the trigger script.
See Section 9, “Special requirements of uninstallation scripts and triggers” for more information.
Trigger scripts receive two arguments.
The first one, $1, like
%pre,
%post,
%preun, and
%postun scripts,
gives the count of how many versions of the triggered package
(the trigger's package) remain installed
after the current package is installed or uninstalled.
If the trigger is invoked because of some other package's installation
or uninstallation, this count will obviously remain unchanged.
The second argument gives the count of how many versions of triggering
package (the package whose resources set off the trigger) will remain
installed.
Consider a system that may have one of two E-mail server packages installed:
“speedmailpro” or
“emailexpress”.
These packages install /usr/bin/speedmailpro or
/usr/bin/emailexpress accordingly.
The following triggers and scripts, if placed in a separate package, create
a new soft link, /usr/bin/mail that automatically points
to one of the two competing E-mail server packages, whichever one is
installed.
The soft link gets automatically updated if one E-mail server package is
replaced by the other one:
%triggerin -- speedmailpro
ln -fs /usr/bin/speedmailpro /usr/bin/mail
%triggerin -- emailexpress
ln -fs /usr/bin/emailexpress /usr/bin/mail
%triggerun -- speedmailpro
test $2 = 0 || exit 0
if test -f /usr/bin/emailexpress
then
ln -fs /usr/bin/emailexpress /usr/bin/mail
else
rm -f /usr/bin/mail
fi
%triggerun -- emailexpress
test $2 = 0 || exit 0
if test -f /usr/bin/speedmailpro
then
ln -fs /usr/bin/speedmailpro /usr/bin/mail
else
rm -f /usr/bin/mail
fi
%postun
if test $1 = 0
then
rm -f /usr/bin/mail
fi
The first two triggers create the soft link that points to the latest
installed package.
Note that the trigger scripts runs either when this package is installed
and either speedmailpro or emailexpress
are already present, or when these two packages are installed later on.
The last two triggers check if the E-mail server packages are
about to be removed.
If so, the soft link gets repointed to the other server package, if it is
installed.
The final %postun script removes the soft link when the
trigger package itself gets removed.
Recall that packages are updated by installing the new version of the package
first, so there's temporarily two versions of the same package present.
Then, the older package is removed, so the argument to
%postun will be “1” in this situation, because
one version of the package, the new one, will remain after the old one
is uninstalled.
%postun should not remove the soft link in this situation.
The soft link should be removed only if this trigger package is really
uninstalled.
This example is for illustrative purposes only. There's usually a better way to accomplish something like this. Triggers exist only as a last ditch measure, where nothing better works. Triggers should be avoided, as their presence indicates a an underlying packaging or a design problem. Properly designed and packaged applications should never need triggers.