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.

Line 7:

Line 6:

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

+

#* EPEL5: i386, ppc, x86_64

+

#* EPEL6: i686, ppc64, x86_64

+

#* EPEL7: ppc64, 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.

# 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 22:

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 and earlier ==

−

== Scrollkeeper ==

+

=== Provides and Requires Filtering ===

−

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.

+

+

{{admon/caution|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]]

+

+

==== 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) ====

+

+

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

−

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>

<pre>

−

BuildRequires: scrollkeeper

+

%prep

−

Requires(post): scrollkeeper

+

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

−

Requires(postun): scrollkeeper

+

−

...

+

−

%post

+

−

scrollkeeper-update -q -o %{_datadir}/omf/%{name} || :

+

−

%postun

+

cat << \EOF > %{name}-prov

−

scrollkeeper-update -q || :

+

#!/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}

</pre>

</pre>

−

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

−

{{Anchor|GConf}}

+

==== External filtering ====

−

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

+

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.

<pre>

<pre>

−

Requires(pre): GConf2

+

Source98: filter-provides.sh

−

Requires(post): GConf2

+

Source99: filter-requires.sh

−

Requires(preun): GConf2

+

−

...

+

%global __perl_provides %{SOURCE98}

−

%pre

+

%global __perl_requires %{SOURCE99}

−

if [ "$1" -gt 1 ] ; then

+

</pre>

−

export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`

+

where filter-provides.sh contains:

−

gconftool-2 --makefile-uninstall-rule \

+

<pre>

−

%{_sysconfdir}/gconf/schemas/[NAME] .schemas >/dev/null || :

+

#!/bin/sh

−

fi

+

/usr/lib/rpm/perl.prov $* |

+

sed -e '/perl(unwanted_provide)/d'

+

</pre>

+

and filter-requires.sh contains:

+

<pre>

+

#!/bin/sh

+

/usr/lib/rpm/perl.req $* |

+

sed -e '/perl(unwanted_require)/d'

</pre>

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

+

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

<pre>

<pre>

−

%post

+

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

−

export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`

+

−

gconftool-2 --makefile-install-rule \

+

−

%{_sysconfdir}/gconf/schemas/[NAME] .schemas > /dev/null || :

+

</pre>

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

+

Alternately, simply use %{pear_phpdir} instead.

+

+

=== The %license tag ===

+

+

The license tag is not supported by EL6 or EL5. This can be worked around by adding the following magic just after <code>%files</code>:

+

<pre>

<pre>

−

%preun

+

%{!?_licensedir:%global license %doc}

−

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>

</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.

+

This does not need to be made conditional on any specific Fedora or EPEL release; it does nothing on the releases which already have <code>%license</code>

+

+

== 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 ==

+

=== PHP ABI Check Handling ===

For Fedora '''EPEL 5''':

For Fedora '''EPEL 5''':

<pre>

<pre>

Line 103:

Line 148:

No API/ABI dependencies are available for Fedora '''EPEL 4''' packages.

No API/ABI dependencies are available for Fedora '''EPEL 4''' packages.

−

== PHP PECL Module 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}:

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>

<pre>

Line 120:

Line 165:

</pre>

</pre>

−

== PHP PEAR Macros ==

+

=== pkgconfig ===

−

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:

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>

<pre>

−

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

+

%files

+

%{_bindir}/orient.py

+

%exclude %{_bindir}/orient.pyc

+

%exclude %{_bindir}/orient.pyo

+

</pre></li>

+

</ol>

+

+

=== 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>

</pre>

−

Alternately, simply use %{pear_phpdir} instead.

+

=== Group tag ===

−

== Perl Provides and Requires Filtering ==

+

rpm in EPEL5 and below requires a Group: tag.

−

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.

+

=== BuildRoot tag ===

−

{{admon/caution|EPEL ONLY|These filtering mechanisms are considered deprecated in Fedora packages and must not be used there.}}

+

rpm in EPEL5 and below does not automatically provide a value for the ''BuildRoot'' tag, so one must be provided in the spec by the packager.

−

=== In %prep (preferred) ===

+

The ''BuildRoot'' value MUST be below <code>%{_tmppath}/</code> and MUST contain at least <code>%{name}</code>, <code>%{version}</code> and <code>%{release}</code>. It may invoke <code>mktemp</code> since this is guaranteed to exist on every system. From there, packagers are expected to use a sane ''BuildRoot''.

−

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

+

The ''recommended'' values for the ''BuildRoot'' tag are (in descending order of preference) :

+

<pre>

+

%(mktemp -ud %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)

+

%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)

+

%{_tmppath}/%{name}-%{version}-%{release}-root

+

</pre>

+

If unsure, simply pick the first.

+

+

{{Anchor|PreppingBuildRootForInstall}}

+

==== Prepping BuildRoot For %install ====

+

It is important to properly prepare the ''BuildRoot'' in the <code>%install</code> section of your package before it is used as rpm in EPEL5 and below does not do this automatically. Package for these releases MUST have an %install section that begins with either:

<pre>

<pre>

−

%prep

+

%install

−

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

+

rm -rf %{buildroot}

+

</pre>

−

cat << \EOF > %{name}-prov

+

or

−

#!/bin/sh

+

−

%{__perl_provides} $* |\

+

−

sed -e '/perl(unwanted_provide)/d'

+

−

EOF

+

−

%global __perl_provides %{_builddir}/%{name}-%{version}/%{name}-prov

+

<pre>

−

chmod +x %{__perl_provides}

+

%install

+

rm -rf $RPM_BUILD_ROOT

+

</pre>

+

This is to ensure that the ''BuildRoot'' will be created fresh during the <code>%install</code> section.

−

cat << \EOF > %{name}-req

+

==== Cleaning BuildRoot in %clean ====

−

#!/bin/sh

+

The %clean section is not required for F-13 and above, and EPEL 6 and above. EPEL 5 MUST have a %clean section that cleans the buildroot:

−

%{__perl_requires} $* |\

+

−

sed -e '/perl(unwanted_require)/d'

+

−

EOF

+

−

%global __perl_requires %{_builddir}/%{name}-%{version}/%{name}-req

+

<pre>

−

chmod +x %{__perl_requires}

+

%clean

+

rm -rf %{buildroot}

</pre>

</pre>

−

=== External filtering ===

+

or

−

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.

+

<pre>

+

%clean

+

rm -rf $RPM_BUILD_ROOT

+

</pre>

+

{{Anchor|scrollkeeper}}

+

+

=== 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.

<pre>

<pre>

−

Source98: filter-provides.sh

+

BuildRequires: scrollkeeper

−

Source99: filter-requires.sh

+

Requires(post): scrollkeeper

+

Requires(postun): scrollkeeper

+

...

+

%post

+

scrollkeeper-update -q -o %{_datadir}/omf/%{name} || :

−

%global __perl_provides %{SOURCE98}

+

%postun

−

%global __perl_requires %{SOURCE99}

+

scrollkeeper-update -q || :

</pre>

</pre>

−

where filter-provides.sh contains:

+

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

+

+

{{Anchor|GConf}}

+

=== 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>

<pre>

−

#!/bin/sh

+

Requires(pre): GConf2

−

/usr/lib/rpm/perl.prov $* |

+

Requires(post): GConf2

−

sed -e '/perl(unwanted_provide)/d'

+

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>

</pre>

−

and filter-requires.sh contains:

+

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>

<pre>

−

#!/bin/sh

+

%post

−

/usr/lib/rpm/perl.req $* |

+

export GCONF_CONFIG_SOURCE=`gconftool-2 --get-default-source`

−

sed -e '/perl(unwanted_require)/d'

+

gconftool-2 --makefile-install-rule \

+

%{_sysconfdir}/gconf/schemas/[NAME] .schemas > /dev/null || :

</pre>

</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:Policy]]

Latest revision as of 01:43, 9 July 2015

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.

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.

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.

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

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:

Rename scripts in %{_bindir} to not have a .py extension: For instance, from /usr/bin/orient.py to /usr/bin/orient.

EL 5 and earlier do not support noarch subpackages. If your build fails due to unpackaged debuginfo files ensure that the BuildArch: noarch is wrapped in an if to make sure its not used on EL-5 and earlier.

rpm in EPEL5 and below does not automatically provide a value for the BuildRoot tag, so one must be provided in the spec by the packager.

The BuildRoot value MUST be below %{_tmppath}/ and MUST contain at least %{name}, %{version} and %{release}. It may invoke mktemp since this is guaranteed to exist on every system. From there, packagers are expected to use a sane BuildRoot.

The recommended values for the BuildRoot tag are (in descending order of preference) :

It is important to properly prepare the BuildRoot in the %install section of your package before it is used as rpm in EPEL5 and below does not do this automatically. Package for these releases MUST have an %install section that begins with either:

%install
rm -rf %{buildroot}

or

%install
rm -rf $RPM_BUILD_ROOT

This is to ensure that the BuildRoot will be created fresh during the %install section.

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.