EPEL:Packaging

From FedoraProject

(Difference between revisions)
Jump to: navigation, search
(Limited Arch Packages: Add note about ExclusiveArch)
(Add a big chunk of scriptlets which are now not to be used in Fedora.)
 
(46 intermediate revisions by 15 users not shown)
Line 1: Line 1:
= EPEL Specific Packaging Guidelines =
+
This page contains guidelines which are no longer relevant to Fedora, but still apply to EPEL packages. 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).
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.
 
As a reminder, these guidelines only apply to EPEL packages, not to Fedora packages.
  
{{Anchor|LimitedArchPackages}}
+
== The %license tag ==
 +
 
 +
RHEL6 does not include a definition of the <code>%license</code> macro, so the <code>epel-rpm-macros</code> package (which is present for every build) will map it to <code>%doc</code>.  This renders it unnecessary to define <code>%license</code> by hand.  However, due to bugs in the SCL macros, this definition will '''not''' exist if the SCL macros package is present on the system.  This should not affect packages when they are built in the build system, but users who do have have the SCL macros installed may see issues when building such packages locally.
 +
 
 
== Limited Arch Packages ==
 
== Limited Arch Packages ==
  
When RHEL ships a package for only a subset of available arches, it's possibly for EPEL to ship that SAME package in order to satisfy dependencies in the other arches in EPEL. In order to do this:  
+
When RHEL ships a package for only a subset of available arches, it's possibly for EPEL to ship that '''same''' package in order to satisfy dependencies in the other arches in EPEL. In order to do this:  
  
# Make sure the package is not shipped on all arches. EPEL5: (ppc/i386/x86_64) EPEL6: (ppc64/i686/x86_64).
+
# Make sure the package is not shipped for all architectures. The valid architectures are:  
 +
#* EPEL6: i686, ppc64, x86_64
 +
#* EPEL7: aarch64, ppc64, ppc64le, x86_64.
 
# Make sure the package meets the Fedora licensing and distribution rules. Nothing non-free or under an unacceptable license.  
 
# Make sure the package meets the Fedora licensing and distribution rules. Nothing non-free or under an unacceptable license.  
 
# Notify the epel-devel list of your intention to add this package.  
 
# Notify the epel-devel list of your intention to add this package.  
 
# Change the release of the package to have a leading 0. EXAMPLE: RHEL has foobar-1.0-1, you change it to foobar-1.0-0.1 for EPEL.
 
# Change the release of the package to have a leading 0. EXAMPLE: RHEL has foobar-1.0-1, you change it to foobar-1.0-0.1 for EPEL.
 
# Add a Changelog entry that the package was added to EPEL and has a 0 leading version to keep it older than RHEL.  
 
# Add a Changelog entry that the package was added to EPEL and has a 0 leading version to keep it older than RHEL.  
# Submit a SCM request asking for the el4/5/6 branch you need.  
+
# Submit a [https://admin.fedoraproject.org/pkgdb package db] request asking for the el5, el6 or epel7 branch you need.  
 
# Import and build your package, submit as update.  
 
# Import and build your package, submit as update.  
 
# Watch the RHEL version of the package. When it updates, you should update the EPEL version too. You should never update other than that.  
 
# Watch the RHEL version of the package. When it updates, you should update the EPEL version too. You should never update other than that.  
Line 20: Line 24:
 
NOTE: Do '''not''' add ExclusiveArch tags, this will break building on the other architectures!
 
NOTE: Do '''not''' add ExclusiveArch tags, this will break building on the other architectures!
  
{{Anchor|scrollkeeper}}
+
== EPEL 6 ==
  
== Scrollkeeper ==
+
=== SysV initscripts ===
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.
+
[[EPEL:SysVInitScripts|SysV initscripts]] are used only in EPEL5 and 6. EPEL7 packages MUST provide systemd units as described in [[Packaging:Systemd]].
<pre>
+
BuildRequires: scrollkeeper
+
Requires(post): scrollkeeper
+
Requires(postun): scrollkeeper
+
...
+
%post
+
scrollkeeper-update -q -o %{_datadir}/omf/%{name} || :
+
  
%postun
+
=== Provides and Requires Filtering ===
scrollkeeper-update -q || :
+
</pre>
+
These two scriptlets tell scrollkeeper to update its indexes to account for the new scrollkeeper files.
+
  
{{Anchor|GConf}}
+
{{admon/caution|EPEL ONLY|These filtering mechanisms are considered deprecated in Fedora packages and must not be used there.}}
== 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:
+
  
<pre>
+
==== Generic Filtering on EPEL6 ====
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
+
</pre>
+
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:
+
On EPEL6, the version of rpm is too old to support the Fedora methods of filtering Provides and Requires.  Please the older guidelines instead: [[EPEL:Packaging_Autoprovides_and_Requires_Filtering]]
<pre>
+
%post
+
export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`
+
gconftool-2 --makefile-install-rule \
+
%{_sysconfdir}/gconf/schemas/[NAME] .schemas > /dev/null || :
+
</pre>
+
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:
+
==== In %prep (preferred) ====
<pre>
+
%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
+
</pre>
+
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 [https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173869 Bug #173869] .  If you are building for EPEL-4, you need to add <code> killall -HUP gconfd-2 > /dev/null || : </code> after the gconftool-2 calls in all the scriptlets.
+
 
+
== PHP ABI Check Handling ==
+
For Fedora '''EPEL 5''':
+
<pre>
+
%global php_apiver  %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1)
+
 
+
BuildRequires: php-devel
+
Requires:      php-api = %{php_apiver}
+
</pre>
+
There is no way of checking the ABI with packages for Fedora EPEL 5.
+
 
+
For a spec file which is compatible with both Fedora and EPEL 5:
+
<pre>
+
%global php_apiver  %((echo 0; php -i 2>/dev/null | sed -n 's/^PHP API => //p') | tail -1)
+
 
+
%if 0%{?php_zend_api}
+
Requires:    php(zend-abi) = %{php_zend_api}
+
Requires:    php(api) = %{php_core_api}
+
%else
+
Requires:    php-api = %{php_apiver}
+
%endif
+
</pre>
+
 
+
No API/ABI dependencies are available for Fedora '''EPEL 4''' packages.
+
 
+
== PHP PECL Module Scriptlets ==
+
On EPEL (EL-4/EL-5), the Fedora scriptlets for properly registering and unregistering the module have to be wrapped with conditionals checking for the existence of %{pecl_install} and %{pecl_uninstall}:
+
<pre>
+
%if 0%{?pecl_install:1}
+
%post
+
%{pecl_install} %{pecl_xmldir}/%{name}.xml >/dev/null || :
+
%endif
+
 
+
 
+
%if 0%{?pecl_uninstall:1}
+
%postun
+
if [ $1 -eq 0 ]  ; then
+
%{pecl_uninstall} %{pecl_name} >/dev/null || :
+
fi
+
%endif
+
</pre>
+
 
+
== Perl Provides and Requires Filtering ==
+
 
+
Unfortunately, the modern macros for Provides and Requires Filtering ([[Packaging:AutoProvidesAndRequiresFiltering]]) do not work for EPEL 5 or older. There are two mechanisms for filtering Perl Provides and Requires in EPEL, either In %prep or via External scripts.
+
 
+
{{admon/caution|EPEL ONLY|These filtering mechanisms are considered deprecated in Fedora packages and must not be used there.}}
+
 
+
=== In %prep (preferred) ===
+
  
 
Filtering can be done entirely in the SPEC file, in the %prep section:
 
Filtering can be done entirely in the SPEC file, in the %prep section:
Line 154: Line 66:
 
</pre>
 
</pre>
  
=== External filtering ===
+
==== External filtering ====
  
 
Or the script can be placed in an external file and referenced from the specfile.  This is worse than the above because the full path of the to-be-overridden script needs to be hardcoded into the file, ignoring the system rpmbuild config.  It is, however, the method used by a significant number of existing packages.
 
Or the script can be placed in an external file and referenced from the specfile.  This is worse than the above because the full path of the to-be-overridden script needs to be hardcoded into the file, ignoring the system rpmbuild config.  It is, however, the method used by a significant number of existing packages.
Line 177: Line 89:
 
sed -e '/perl(unwanted_require)/d'
 
sed -e '/perl(unwanted_require)/d'
 
</pre>
 
</pre>
 +
 +
=== PHP PEAR Macros ===
 +
In EPEL6, the "%{pear_macrodir}" macro is not defined. The simplest fix is to add this line to your spec file:
 +
<pre>
 +
%{!?pear_metadir: %global pear_metadir %{pear_phpdir}}
 +
</pre>
 +
 +
Alternately, simply use %{pear_phpdir} instead.
 +
 +
=== Python ===
 +
Multiple macros are being used in recent python packages that are not available in EPEL6.
 +
{| class="mw-collapsible wikitable" style="width:100%"
 +
! Macro name
 +
! Line to fix it
 +
! Possible alternative
 +
|-
 +
| %{__python2}
 +
| %{!?__python2: %global __python2 /usr/bin/python2}
 +
| %{__python}
 +
|-
 +
| %{python2_sitelib}
 +
| %{!?python2_sitelib: %global python2_sitelib %(%{__python2} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")}
 +
| %{python_sitelib}
 +
|-
 +
| %{python2_sitearch}
 +
| %{!?python2_sitearch: %global python2_sitearch %(%{__python2} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib(1))")}
 +
| %{python_sitearch}
 +
|-
 +
| %py2_build
 +
| %{!?py2_build: %global py2_build %{expand: CFLAGS="%{optflags}" %{__python2} setup.py %{?py_setup_args} build --executable="%{__python2} -s"}}
 +
| CFLAGS="%{optflags}" %{__python} setup.py %{?py_setup_args} build --executable="%{__python2} -s"
 +
|-
 +
| %py2_install
 +
| %{!?py2_install: %global py2_install %{expand: CFLAGS="%{optflags}" %{__python2} setup.py %{?py_setup_args} install -O1 --skip-build --root %{buildroot}}}
 +
| CFLAGS="%{optflags}" %{__python} setup.py %{?py_setup_args} install -O1 --skip-build --root %{buildroot}
 +
|}
 +
 +
== Scriptlets ==
 +
 +
Fedora has been moving towards the use of file triggers and away from requiring that packagers cut and paste scriptlets into loads of packages.  These scriptlets would still be needed for EPEL, and as scriptlets are no longer needed in any Fedora release, they're moved here.
 +
 +
=== GSettings Schema ===
 +
GSettings is the configuration system used by the GNOME 3 desktop. It replaces the older GConf
 +
system, which was used in GNOME 2. GSettings has pluggable backends, the 'native' one for GNOME is using DConf to store settings. The GSettings API and utilities are part of the glib2 package.
 +
 +
Programs which use GSettings install schema information including default values in the directory %{_datadir}/glib-2.0/schemas. Schema files are xml files with the extension .gschema.xml. At runtime, GSettings uses the schemas in a compiled binary (but arch-neutral) form, which is created by running the glib-compile-schemas utility. /usr/bin/glib-compile-schemas must be run whenever the set of installed schemas changes.
 +
 +
<pre>
 +
%postun
 +
if [ $1 -eq 0 ] ; then
 +
    /usr/bin/glib-compile-schemas %{_datadir}/glib-2.0/schemas &> /dev/null || :
 +
fi
 +
 +
%posttrans
 +
    /usr/bin/glib-compile-schemas %{_datadir}/glib-2.0/schemas &> /dev/null || :
 +
</pre>
 +
 +
=== gdk-pixbuf loaders ===
 +
gdk-pixbuf is a library that is part of the gdk-pixbuf2 package. It is for loading images in various formats in GNOME. gdk-pixbuf can be extended by implementing loaders for image formats in loadable modules. These loadable modules have to be installed in %{_libdir}/gdk-pixbuf-2.0/2.10.0/loaders. To avoid opening all modules in that directory unnecessarily, gdk-pixbuf maintains a cache with information about the available modules in the text file %{_libdir}/gdk-pixbuf-2.0/2.10.0/loaders.cache. This cache file needs to be updated when the set of installed modules changes, by calling the /usr/bin/gdk-pixbuf-query-loaders binary. Multilib considerations force us to install the binary in -32 and -64 variants.
 +
 +
The scriptlets to maintain the cache file are:
 +
<pre>
 +
%postun
 +
    /usr/bin/gdk-pixbuf-query-loaders-%{__isa_bits} --update-cache &> /dev/null || :
 +
 +
%post
 +
if [ $1 -eq 1 ] ; then
 +
    # For upgrades, the cache will be regenerated by the new package's %postun
 +
    /usr/bin/gdk-pixbuf-query-loaders-%{__isa_bits} --update-cache &> /dev/null || :
 +
fi
 +
</pre>
 +
 +
Note the use of %{__isa_bits}, which is an rpm macro that expands to either 32 or 64,
 +
depending on the architecture of the package.
 +
 +
=== GTK+ modules ===
 +
The GTK+ toolkit (in the gtk3 package) can be extended by loadable modules which can provide theme engines, input methods, print backends or other functionality. These modules have to be installed in subdirectories of %{_libdir}/gtk-3.0 or %{_libdir}/gtk-3.0/3.0.0. For the input methods, GTK+ maintains a cache in the text file %{_libdir}/gtk-3.0/3.0.0/immodules.cache. This cache file needs to be updated when the set of installed input methods changes, by calling the gtk-query-immodules-3.0 binary. Multilib considerations force us to install the binary in -32 and -64 variants.
 +
 +
The scriptlets to maintain the cache file are:
 +
<pre>
 +
%postun
 +
/usr/bin/gtk-query-immodules-3.0-%{__isa_bits} --update-cache &> /dev/null || :
 +
 +
%post
 +
if [ $1 -eq 1 ] ; then
 +
    # For upgrades, the cache will be regenerated by the new package's %postun
 +
    /usr/bin/gtk-query-immodules-3.0-%{__isa_bits} --update-cache &> /dev/null || :
 +
fi
 +
</pre>
 +
 +
The 3.0 in the binary name is there because gtk2 has its own utility for the same purpose, called gtk-query-immodules-2.0. Note the use of %{__isa_bits}, which is an rpm macro that expands to either 32 or 64, depending on the architecture of the package.
 +
 +
=== GIO modules ===
 +
GIO is a library that is part of the glib2 package. It is a low-level part of the GNOME stack.  GIO can be extended by implementing [http://library.gnome.org/devel/gio/2.26/extending-gio.html extension points] in loadable modules. These loadable modules have to be installed in %{_libdir}/gio/modules. To avoid opening all modules in that directory
 +
unnecessarily, GIO maintains a cache with information about the available modules in the
 +
text file giomodule.cache in the same directory. This cache file needs to be updated when the set of installed modules changes, by calling the gio-querymodules binary. Multilib considerations force us to install the binary in -32 and -64 variants.
 +
 +
The scriptlets to maintain the cache file are:
 +
<pre>
 +
%postun
 +
/usr/bin/gio-querymodules-%{__isa_bits} %{_libdir}/gio/modules &> /dev/null || :
 +
 +
%post
 +
# We run this after every install or upgrade because of a cornercase
 +
# when installing the second architecture of a multilib package
 +
/usr/bin/gio-querymodules-%{__isa_bits} %{_libdir}/gio/modules || :
 +
</pre>
 +
 +
Note the use of %{__isa_bits}, which is an rpm macro that expands to either 32 or 64,
 +
depending on the architecture of the package.
 +
 +
=== mimeinfo ===
 +
Use this when a package drops an XML file in %{_datadir}/mime/packages.
 +
<pre>
 +
%post
 +
/bin/touch --no-create %{_datadir}/mime/packages &>/dev/null || :
 +
 +
%postun
 +
if [ $1 -eq 0 ] ; then
 +
  /usr/bin/update-mime-database %{_datadir}/mime &> /dev/null || :
 +
fi
 +
 +
%posttrans
 +
/usr/bin/update-mime-database %{?fedora:-n} %{_datadir}/mime &> /dev/null || :
 +
</pre>
 +
 +
Note that similarly to the gtk-update-icon-cache code, these scriptlets should be run only if the user has update-mime-info installed and without a specific Requires: shared-mime-info.  If shared-mime-info is not installed, update-mime-database won't be run when this package is installed.  This does not matter because it will be run when the shared-mime-info package is installed.
 +
 +
 +
[[Category:EPEL]]
 +
[[Category:Policy]]

Latest revision as of 18:46, 8 June 2017

This page contains guidelines which are no longer relevant to Fedora, but still apply to EPEL packages. 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.

Contents

[edit] The %license tag

RHEL6 does not include a definition of the %license macro, so the epel-rpm-macros package (which is present for every build) will map it to %doc. This renders it unnecessary to define %license by hand. However, due to bugs in the SCL macros, this definition will not exist if the SCL macros package is present on the system. This should not affect packages when they are built in the build system, but users who do have have the SCL macros installed may see issues when building such packages locally.

[edit] Limited Arch Packages

When RHEL ships a package for only a subset of available arches, it's possibly for EPEL to ship that same package in order to satisfy dependencies in the other arches in EPEL. In order to do this:

  1. Make sure the package is not shipped for all architectures. The valid architectures are:
    • EPEL6: i686, ppc64, x86_64
    • EPEL7: aarch64, ppc64, ppc64le, x86_64.
  2. Make sure the package meets the Fedora licensing and distribution rules. Nothing non-free or under an unacceptable license.
  3. Notify the epel-devel list of your intention to add this package.
  4. Change the release of the package to have a leading 0. EXAMPLE: RHEL has foobar-1.0-1, you change it to foobar-1.0-0.1 for EPEL.
  5. Add a Changelog entry that the package was added to EPEL and has a 0 leading version to keep it older than RHEL.
  6. Submit a package db request asking for the el5, el6 or epel7 branch you need.
  7. Import and build your package, submit as update.
  8. Watch the RHEL version of the package. When it updates, you should update the EPEL version too. You should never update other than that.

NOTE: Do not add ExclusiveArch tags, this will break building on the other architectures!

[edit] EPEL 6

[edit] SysV initscripts

SysV initscripts are used only in EPEL5 and 6. EPEL7 packages MUST provide systemd units as described in Packaging:Systemd.

[edit] Provides and Requires Filtering

Stop (medium size).png
EPEL ONLY
These filtering mechanisms are considered deprecated in Fedora packages and must not be used there.

[edit] Generic Filtering on EPEL6

On EPEL6, the version of rpm is too old to support the Fedora methods of filtering Provides and Requires. Please the older guidelines instead: EPEL:Packaging_Autoprovides_and_Requires_Filtering

[edit] In %prep (preferred)

Filtering can be done entirely in the SPEC file, in the %prep section:

%prep
%setup -q -n Foo-%{version}

cat << \EOF > %{name}-prov
#!/bin/sh
%{__perl_provides} $* |\
sed -e '/perl(unwanted_provide)/d'
EOF

%global __perl_provides %{_builddir}/%{name}-%{version}/%{name}-prov
chmod +x %{__perl_provides}


cat << \EOF > %{name}-req
#!/bin/sh
%{__perl_requires} $* |\
sed -e '/perl(unwanted_require)/d'
EOF

%global __perl_requires %{_builddir}/%{name}-%{version}/%{name}-req
chmod +x %{__perl_requires}

[edit] External filtering

Or the script can be placed in an external file and referenced from the specfile. This is worse than the above because the full path of the to-be-overridden script needs to be hardcoded into the file, ignoring the system rpmbuild config. It is, however, the method used by a significant number of existing packages.

Source98: filter-provides.sh
Source99: filter-requires.sh

%global __perl_provides %{SOURCE98}
%global __perl_requires %{SOURCE99}

where filter-provides.sh contains:

#!/bin/sh
/usr/lib/rpm/perl.prov $* |
sed -e '/perl(unwanted_provide)/d'

and filter-requires.sh contains:

#!/bin/sh
/usr/lib/rpm/perl.req $* |
sed -e '/perl(unwanted_require)/d'

[edit] PHP PEAR Macros

In EPEL6, the "%{pear_macrodir}" macro is not defined. The simplest fix is to add this line to your spec file:

%{!?pear_metadir: %global pear_metadir %{pear_phpdir}}

Alternately, simply use %{pear_phpdir} instead.

[edit] Python

Multiple macros are being used in recent python packages that are not available in EPEL6.

Macro name Line to fix it Possible alternative
 %{__python2}  %{!?__python2: %global __python2 /usr/bin/python2}  %{__python}
 %{python2_sitelib}  %{!?python2_sitelib: %global python2_sitelib %(%{__python2} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())")}  %{python_sitelib}
 %{python2_sitearch}  %{!?python2_sitearch: %global python2_sitearch %(%{__python2} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib(1))")}  %{python_sitearch}
 %py2_build  %{!?py2_build: %global py2_build %{expand: CFLAGS="%{optflags}" %{__python2} setup.py %{?py_setup_args} build --executable="%{__python2} -s"}} CFLAGS="%{optflags}" %{__python} setup.py %{?py_setup_args} build --executable="%{__python2} -s"
 %py2_install  %{!?py2_install: %global py2_install %{expand: CFLAGS="%{optflags}" %{__python2} setup.py %{?py_setup_args} install -O1 --skip-build --root %{buildroot}}} CFLAGS="%{optflags}" %{__python} setup.py %{?py_setup_args} install -O1 --skip-build --root %{buildroot}

[edit] Scriptlets

Fedora has been moving towards the use of file triggers and away from requiring that packagers cut and paste scriptlets into loads of packages. These scriptlets would still be needed for EPEL, and as scriptlets are no longer needed in any Fedora release, they're moved here.

[edit] GSettings Schema

GSettings is the configuration system used by the GNOME 3 desktop. It replaces the older GConf system, which was used in GNOME 2. GSettings has pluggable backends, the 'native' one for GNOME is using DConf to store settings. The GSettings API and utilities are part of the glib2 package.

Programs which use GSettings install schema information including default values in the directory %{_datadir}/glib-2.0/schemas. Schema files are xml files with the extension .gschema.xml. At runtime, GSettings uses the schemas in a compiled binary (but arch-neutral) form, which is created by running the glib-compile-schemas utility. /usr/bin/glib-compile-schemas must be run whenever the set of installed schemas changes.

%postun
if [ $1 -eq 0 ] ; then
    /usr/bin/glib-compile-schemas %{_datadir}/glib-2.0/schemas &> /dev/null || :
fi

%posttrans
    /usr/bin/glib-compile-schemas %{_datadir}/glib-2.0/schemas &> /dev/null || :

[edit] gdk-pixbuf loaders

gdk-pixbuf is a library that is part of the gdk-pixbuf2 package. It is for loading images in various formats in GNOME. gdk-pixbuf can be extended by implementing loaders for image formats in loadable modules. These loadable modules have to be installed in %{_libdir}/gdk-pixbuf-2.0/2.10.0/loaders. To avoid opening all modules in that directory unnecessarily, gdk-pixbuf maintains a cache with information about the available modules in the text file %{_libdir}/gdk-pixbuf-2.0/2.10.0/loaders.cache. This cache file needs to be updated when the set of installed modules changes, by calling the /usr/bin/gdk-pixbuf-query-loaders binary. Multilib considerations force us to install the binary in -32 and -64 variants.

The scriptlets to maintain the cache file are:

%postun
    /usr/bin/gdk-pixbuf-query-loaders-%{__isa_bits} --update-cache &> /dev/null || :

%post
if [ $1 -eq 1 ] ; then
    # For upgrades, the cache will be regenerated by the new package's %postun
    /usr/bin/gdk-pixbuf-query-loaders-%{__isa_bits} --update-cache &> /dev/null || :
fi

Note the use of %{__isa_bits}, which is an rpm macro that expands to either 32 or 64, depending on the architecture of the package.

[edit] GTK+ modules

The GTK+ toolkit (in the gtk3 package) can be extended by loadable modules which can provide theme engines, input methods, print backends or other functionality. These modules have to be installed in subdirectories of %{_libdir}/gtk-3.0 or %{_libdir}/gtk-3.0/3.0.0. For the input methods, GTK+ maintains a cache in the text file %{_libdir}/gtk-3.0/3.0.0/immodules.cache. This cache file needs to be updated when the set of installed input methods changes, by calling the gtk-query-immodules-3.0 binary. Multilib considerations force us to install the binary in -32 and -64 variants.

The scriptlets to maintain the cache file are:

%postun
/usr/bin/gtk-query-immodules-3.0-%{__isa_bits} --update-cache &> /dev/null || :

%post
if [ $1 -eq 1 ] ; then
    # For upgrades, the cache will be regenerated by the new package's %postun
    /usr/bin/gtk-query-immodules-3.0-%{__isa_bits} --update-cache &> /dev/null || :
fi

The 3.0 in the binary name is there because gtk2 has its own utility for the same purpose, called gtk-query-immodules-2.0. Note the use of %{__isa_bits}, which is an rpm macro that expands to either 32 or 64, depending on the architecture of the package.

[edit] GIO modules

GIO is a library that is part of the glib2 package. It is a low-level part of the GNOME stack. GIO can be extended by implementing extension points in loadable modules. These loadable modules have to be installed in %{_libdir}/gio/modules. To avoid opening all modules in that directory unnecessarily, GIO maintains a cache with information about the available modules in the text file giomodule.cache in the same directory. This cache file needs to be updated when the set of installed modules changes, by calling the gio-querymodules binary. Multilib considerations force us to install the binary in -32 and -64 variants.

The scriptlets to maintain the cache file are:

%postun
/usr/bin/gio-querymodules-%{__isa_bits} %{_libdir}/gio/modules &> /dev/null || :

%post
# We run this after every install or upgrade because of a cornercase
# when installing the second architecture of a multilib package 
/usr/bin/gio-querymodules-%{__isa_bits} %{_libdir}/gio/modules || :

Note the use of %{__isa_bits}, which is an rpm macro that expands to either 32 or 64, depending on the architecture of the package.

[edit] mimeinfo

Use this when a package drops an XML file in %{_datadir}/mime/packages.

%post
/bin/touch --no-create %{_datadir}/mime/packages &>/dev/null || :

%postun
if [ $1 -eq 0 ] ; then
  /usr/bin/update-mime-database %{_datadir}/mime &> /dev/null || :
fi

%posttrans
/usr/bin/update-mime-database %{?fedora:-n} %{_datadir}/mime &> /dev/null || :

Note that similarly to the gtk-update-icon-cache code, these scriptlets should be run only if the user has update-mime-info installed and without a specific Requires: shared-mime-info. If shared-mime-info is not installed, update-mime-database won't be run when this package is installed. This does not matter because it will be run when the shared-mime-info package is installed.