(Tips for writing scriptlets) |
m (moved User:Toshio/Scriptlet postrans to User:Toshio/Writing scriptlets: section became more generic) |
(No difference)
|
Revision as of 18:22, 21 December 2011
To be added to Packaging:ScriptletSnippets after the Syntax Ordering section.
Writing scriptlets
Some tips for writing good scriptlets
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
for that. For instance, the eclipse plugin scripts touch a file in %{_localstatedir}/lib/rpm/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
Complex scriptlets 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 must not cross scriptlet boundaries. For instance, a single macro should 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.