From Fedora Project Wiki

No edit summary
Line 23: Line 23:


{{Anchor|GConf2}}
{{Anchor|GConf2}}
== GConf2 Scriptlets ==
== GConf Scriptlets ==
In Fedora, we now use macros for our GConf2 scriptlets, but for EL-4 and EL-5, this is not an option. For those targets, please use the old manual scriptlets, as documented below:
In Fedora, we now use macros for our GConf2 scriptlets, but for EL-4 and EL-5, this is not an option. For those targets, please use the old manual scriptlets, as documented below:



Revision as of 15:38, 3 March 2010

EPEL Specific Packaging Guidelines

This page contains guidelines which are no longer relevant to Fedora, but still apply to EPEL packages (EL-4 and/or EL-5). These guidelines are designed to avoid conflict with the larger Fedora Packaging Guidelines, but should any conflicts occur, these guidelines should take precedence (on EPEL packages).

As a reminder, these guidelines only apply to EPEL packages, not to Fedora packages.

Scrollkeeper

For EL-4 and EL-5, Gnome and KDE use the scrollkeeper cataloging system to keep track of documentation installed on the system. Scrollkeeper allows the help system to sort and search documentation metadata stored in .omf files. When you add documentation in these systems you need to make scrollkeeper aware that the documentation has been changed.

Note that we BuildRequires scrollkeeper as most Makefile's are setup to install the necessary scrollkeeper files only if scrollkeeper is present at install time.

BuildRequires:  scrollkeeper
Requires(post): scrollkeeper
Requires(postun): scrollkeeper
...
%post
scrollkeeper-update -q -o %{_datadir}/omf/%{name} || :

%postun
scrollkeeper-update -q || :

These two scriptlets tell scrollkeeper to update its indexes to account for the new scrollkeeper files.

GConf Scriptlets

In Fedora, we now use macros for our GConf2 scriptlets, but for EL-4 and EL-5, this is not an option. For those targets, please use the old manual scriptlets, as documented below:

Requires(pre): GConf2
Requires(post): GConf2
Requires(preun): GConf2
...
%pre
if [ "$1" -gt 1 ] ; then
export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
gconftool-2 --makefile-uninstall-rule \
%{_sysconfdir}/gconf/schemas/[NAME] .schemas >/dev/null || :
fi

In this section we uninstall the old schemas when we upgrade. The way we do this is first to get information about where gconf stores its values via the gconftool-2 --get-default-source line. Then we uninstall the schema from that source. If the package could be upgrading a package which had another name for the schema at one time, then we uncomment the lines to uninstall those as well.

The next section is for installing the new schema:

%post
export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
gconftool-2 --makefile-install-rule \
%{_sysconfdir}/gconf/schemas/[NAME] .schemas > /dev/null || :

Here we do the same things as in the %pre section for upgrading except the gconftool-2 switch used is --makefile-install-rule to install the new schemas instead of the uninstall-rule to remove the old schemas.

The last section deals with deleting the schemas on package removal:

%preun
if [ "$1" -eq 0 ] ; then
export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
gconftool-2 --makefile-uninstall-rule \
%{_sysconfdir}/gconf/schemas/[NAME] .schemas > /dev/null || :
fi

This snippet is nearly the same as the one for upgrading. Why can't we just combine this portion with the %pre portion? The answer is that we want to delete any old versions of the schema during an upgrade. But this has to happen before we install the new version (in the %post script) otherwise we end up removing the schema that the upgrading package installs. However, if it really is a removal that will leave no other instances of this package on the system, we have to clean up the schema before deleting it.

Note: RHEL4 suffers from GConf Bug #173869 . If you are building for EPEL-4, you need to add killall -HUP gconfd-2 > /dev/null || : after the gconftool-2 calls in all the scriptlets.