From Fedora Project Wiki

(aarch64 was added to EPEL7 in 7.3)
(Restructure slightly now that so much EPEL5 cruft has gone away.)
(3 intermediate revisions by 2 users not shown)
Line 3: Line 3:
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.


== Previously required boilerplate ==
== The %license tag ==


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:
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 handHowever, 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.
 
{| class="mw-collapsible wikitable" style="width:100%"
! Item !! Release !! Info
|-
| <code>Buildroot:</code> || EPEL5 || Is set to the buildroot Fedora uses if not specified.
|-
| <code>Group:</code> || EPEL5 || Is set to "Unspecified" if not provided.  Works for subpackages, too, but only if the main package has no specified group.
|-
| <code>%license</code> || EPEL5, 6 || Maps to <code>%doc</code>.  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).
|-
| <code>%install</code> buildroot cleaning || EPEL5 || <code>rm -rf %buildroot</code> will always be inserted at the beginning of %install regardless of whether it is already present.
|-
| <code>%clean</code> || EPEL5 || A <code>%clean</code> section is always providedIf one is already included in the spec, it will be ignored but it must not be the first section after <code>%description</code> (which is not the normal place for the section in any case).  If it is located there, its contents may be appended to the <code>%description</code> instead.
 
|}
 
== %autosetup ==
 
The %autosetup macro is available in all EPEL releases (via epel-rpm-macros for EPEL5 and EPEL6).
 
For EPEL5, there is but a single caveat.  As the old version of RPM in EPEL5 does not support the patches (as well as the sources) table in the lua namespace, it is instead generated by iterating over 100000 possible <code>PatchXXX:</code> entries. If for some reason you have patches numbered higher than <code>Patch100000:</code> then you should set %el5_patches_limit to some value which equals or exceeds the highest patch number you have


== Limited Arch Packages ==
== Limited Arch Packages ==
Line 33: Line 12:


# Make sure the package is not shipped for all architectures. The valid architectures are:  
# Make sure the package is not shipped for all architectures. The valid architectures are:  
#* EPEL5: i386, ppc, x86_64
#* EPEL6: i686, ppc64, x86_64
#* EPEL6: i686, ppc64, x86_64
#* EPEL7: aarch64, ppc64, ppc64le, x86_64.
#* EPEL7: aarch64, ppc64, ppc64le, x86_64.
Line 46: 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!


== EPEL 6 and earlier ==
== EPEL 6 ==
 
=== SysV initscripts ===
 
[[EPEL:SysVInitScripts|SysV initscripts]] are used only in EPEL5 and 6. EPEL7 packages MUST provide systemd units as described in [[Packaging:Systemd]].


=== Provides and Requires Filtering ===
=== Provides and Requires Filtering ===
Line 55: Line 37:


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]]
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]]
==== Perl Provides and Requires on EPEL5 and older ====
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.


==== In %prep (preferred) ====
==== In %prep (preferred) ====
Line 113: Line 91:


=== PHP PEAR Macros ===
=== PHP PEAR Macros ===
On EPEL (EL-5/EL-6), the "%{pear_macrodir}" macro is not defined. The simplest fix is to add this line to your spec file:
In EPEL6, the "%{pear_macrodir}" macro is not defined. The simplest fix is to add this line to your spec file:
<pre>
<pre>
%{!?pear_metadir: %global pear_metadir %{pear_phpdir}}
%{!?pear_metadir: %global pear_metadir %{pear_phpdir}}
Line 121: Line 99:


=== Python ===
=== Python ===
Multiple macros are being used in recent python packages that are not available in EL5 and EL6.
Multiple macros are being used in recent python packages that are not available in EPEL6.
{| class="mw-collapsible wikitable" style="width:100%"
{| class="mw-collapsible wikitable" style="width:100%"
! Macro name
! Macro name
Line 147: Line 125:
| CFLAGS="%{optflags}" %{__python} 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}
|}
|}
== EPEL 5 and earlier ==
=== Building packages for EPEL 5 on non EL5 machines ===
If you are receiving md5sum errors when building on non EL5 machines please try the following steps:
<pre>
1) fedpkg clone <package>
2) fedpkg switch-branch el5
3) <make changes>
4) fedpkg srpm
5) koji build --scratch dist-5E-epel file.el5.src.rpm
6) Verify build completes
7) fedpkg commit
8) fedpkg push
9) fedpkg build
</pre>
=== 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>
=== PHP PECL Module Scriptlets ===
On EPEL5, 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>
=== pkgconfig ===
rpm in EPEL5 does not automatically create dependencies for pkgconfig files.  Packages containing pkgconfig(.pc) files must <code>Requires: pkgconfig</code> (for directory ownership and usability).
=== python byte compilation ===
In EPEL5 the automatic byte compilation of python files that is performed by brp-python-bytecompile byte compiles all files that match *.py  This is undesirable for program files in %{_bindir} and %{_sbindir} because the user will probably never invoke these files, only the main program file and python won't use these files.  There are two workarounds:
<ol>
<li>Rename scripts in %{_bindir} to not have a .py extension:  For instance, from /usr/bin/orient.py to /usr/bin/orient.</li>
<li>Use %exclude to exclude the scripts from the file listing:
<pre>
%files
%{_bindir}/orient.py
%exclude %{_bindir}/orient.pyc
%exclude %{_bindir}/orient.pyo
</pre></li>
</ol>
=== Providing Egg Metadata for Non-setuptools Packages ===
{{admon/note||These instructions are only for distutils in RHEL5.  Fedora and newer EPEL will automatically generate egg-info files.}}
When we need to provide egg metadata in a non-setuptools package because another package requires that functionality we can modify our spec files to generate the egg-info:
<pre>
BuildRequires: python-setuptools
[...]
%build
CFLAGS="%{optflags}" %{__python2} -c 'import setuptools; execfile("setup.py")' build
%install
%{__python2} -c 'import setuptools; execfile("setup.py")' install --skip-build --root %{buildroot}
%files
%{python2_sitelib}/*egg-info
%{python2_sitelib}/[MODULENAME]
</pre>
By importing setuptools before executing setup.py we override the distutils functions that process the file with their setuptools equivalents.  Those functions create the egg-info files.
=== noarch subpackages ===
EL 5 and earlier do not support noarch subpackages.  If your build fails due to unpackaged debuginfo files ensure that the <code>BuildArch: noarch</code> is wrapped in an if to make sure its not used on EL-5 and earlier.
=== xz compression ===
Tar in EL 5 and earlier does not support extracting xz-compressed
tarballs.  To extract such tarballs, use the following %prep section:
<pre>
%prep
xzcat %{SOURCE0} | tar -xf -
%setup -qDT
</pre>
=== Scrollkeeper ===
For 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.
<pre>
BuildRequires:  scrollkeeper
Requires(post): scrollkeeper
Requires(postun): scrollkeeper
...
%post
scrollkeeper-update -q -o %{_datadir}/omf/%{name} || :
%postun
scrollkeeper-update -q || :
</pre>
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-5, this is not an option. For those targets, please use the old manual scriptlets, as documented below:
<pre>
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:
<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:
<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.
=== Scriptlets requirements ===
Do not use the <code>Requires(pre,post)</code> style notation for scriptlet dependencies, because of two bugs in RPM. Instead, they should be split like this:
<pre>
Requires(pre): ...
Requires(post): ...
</pre>
For more information, see [http://www.redhat.com/archives/fedora-devel-list/2004-April/msg00674.html this mailing list post] .


[[Category:EPEL]]
[[Category:EPEL]]
[[Category:Policy]]
[[Category:Policy]]

Revision as of 19:25, 10 April 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.

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.

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!

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

Stop (medium size).png
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}