EPEL Specific Packaging Guidelines

This page contains guidelines which are no longer relevant to Fedora, but still apply to EPEL packages (EL-4, EL-5, and/or EL-6). 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.

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:

Make sure the package is not shipped on all arches. EPEL5: (ppc/i386/x86_64) EPEL6: (ppc64/i686/x86_64).

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.

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.

Submit a SCM request asking for the el4/5/6 branch you need.

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.

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

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.

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.

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.

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.

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}:

PHP PEAR Macros

On EPEL (EL-4/EL-5/EL-6), 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.

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.

EPEL ONLYThese 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:

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.