Zen

Source string Source string

132/10000 · 132

The string is read only.

English Actions
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.
Snippets
Some scriptlets to use in specific situations.
Linker Configuration Files
Packages which place linker configuration files in `+/etc/ld.so.conf.d+` MUST call ldconfig in `+%post+` and `+%postun+` (on all Fedora releases) even if they install no actual libraries. They MUST NOT use the `+%ldconfig+`, `+%ldconfig_post+`, `+%ldconfig_postun+` or `+%ldconfig_scriptlets+` macros to do this, since these macros do not have any effect on Fedora. Instead simply call `+ldconfig+` directly in both `+%post+` and `+%postun+` as well as adding the necessary dependencies when necessary:
%post -p /usr/bin/ldconfig
%postun -p /usr/bin/ldconfig
or, as part of existing `+%post+` or `+%postun+` scriptlets:
Requires(post): /usr/bin/ldconfig
Requires(postun): /usr/bin/ldconfig
[...]
%post
[...]
ldconfig
[...]
%postun
[...]
ldconfig
[...]
If the configuration file added to `+/etc/ld.so.conf.d+` specifies a directory into which other packages may install files, and that directory is not located in the directory hierarchy beneath one of `+/lib+`, `+/usr/lib+`, `+/lib64+` or `+/usr/lib64+`, then the package adding the configuration file MUST also include the following file triggers which cause ldconfig to be run automatically when necessary:
%transfiletriggerin -P 2000000 -- DIRECTORIES
ldconfig
%transfiletriggerpostun -P 2000000 -- DIRECTORIES
ldconfig
Replace `+DIRECTORIES+` with the space-separated list of directories which the package adds to the library search path via the configuration files in `+/etc/ld.so.conf.d+`.
Users and groups
These are discussed on a xref:UsersAndGroups.adoc[separate page].
GConf
GConf is a configuration scheme currently used by the GNOME desktop. Programs which use it setup default values in a `+.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+` file to handle it. If the `+Makefile.am+` file is not configured, this switch won't do anything and you'll need to use the environment variable instead.
Here's the second part:

Loading…

User avatar None

String added in the repository

  1. fedora-docs-l10n/packaging-guidelines
  2. master/pages/Scriptlets
  3. English
Requires(post): /usr/bin/ldconfig
Requires(postun): /usr/bin/ldconfig
[...]
%post
[...]
ldconfig
[...]
%postun
[...]
ldconfig
[...]
Requires(post): /usr/bin/ldconfig
Requires(postun): /usr/bin/ldconfig
[...]
%post
[...]
ldconfig
[...]
%postun
[...]
ldconfig
[...]
yesterday
Browse all string changes

Things to check

Ellipsis

The string uses three dots (...) instead of an ellipsis character (…)

Reset

Glossary

English English
No related strings found in the glossary.

String information

Source string description
type: delimited block .
Flags
no-wrap, read-only
Source string location
./pages/Scriptlets.adoc:237
String age
yesterday
Last updated
yesterday
Source string age
yesterday
Translation file
pot/master/pages/Scriptlets.pot, string 53