User:Toshio/Writing scriptlets

From FedoraProject

< User:Toshio
Revision as of 17:32, 4 January 2012 by Toshio (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page. To be added to Packaging:ScriptletSnippets

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

We're asking that the %{_localstatedir}/lib/rpm-state/ directory be owned by either the rpm or filesystem packages in Fedora. Until that happens, a package that is providing this functionality needs to own %{_localstatedir}/lib/rpm-state/ as well as their subdirectory of it.


Complex scriptlets may be placed in rpm macros. This has two benefits:

  1. The standard package authors only have to remember the macros, not the complex stuff that it does
  2. 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 contain the start of scriptlet tags (for instance, %pre). This also means that a single macro must 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.