EPEL:Packaging

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.

Previously required boilerplate

The epel-rpm-macros package sets defaults for some items and provides other macros which were previously required to be included or manually defined in EPEL6 and/or EPEL5. While these macros were tested with all existing EPEL package, some of them are provided through the use of RPM macro trickery and can have side effects in some cases. The items which are provided:

Item	Release	Info
Buildroot:	EPEL5	Is set to the buildroot Fedora uses if not specified.
Group:	EPEL5	Is set to "Unspecified" if not provided. Works for subpackages, too, but only if the main package has no specified group.
%license	EPEL5, 6	Maps to %doc. Previously required manual definition. Is not defined if the SCL macros package is present on the system (due to bugs in the SCL macros which cause them to fail).
%install buildroot cleaning	EPEL5	rm -rf %buildroot will always be inserted at the beginning of %install regardless of whether it is already present.
%clean	EPEL5	A %clean section is always provided. If one is already included in the spec, it will be ignored but it must not be the first section after %description (which is not the normal place for the section in any case). If it is located there, its contents may be appended to the %description instead.

%autosetup

The %autosetup macro is available in all EPEL releases.

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:
   • EPEL5: i386, ppc, x86_64
   • 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!

EPEL 6

SysV initscripts

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

Provides and Requires Filtering

EPEL ONLY
These filtering mechanisms are considered deprecated in Fedora packages and must not be used there.

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

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}

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'

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.

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}