EPEL packaging examples

Missing-but-built examples

These examples are for the Missing RHEL sub-packages/missing built sub-packages/short term policy.

Missing-but-built workflow

This is an example workflow.

  1. fedpkg request-repo --exception <package>-epel

    • For example: fedpkg request-repo --exception pycairo-epel

  2. fedpkg request-branch --repo <package>-epel epel<version>

    • For example: fedpkg request-branch --repo pycairo-epel epel9

      request-repo and request-branch can be done at the same time as long as request-repo is done first.

  3. Wait until you get an email saying the request is done

  4. fedpkg clone <package>-epel ; cd <package>-epel

    • For example: fedpkg clone pycairo-epel ; cd pycairo-epel

  5. fedpkg retire "For epel only, not Fedora"

  6. fedpkg switch-branch epel<version>

    • For example: fedpkg switch-branch epel9

  7. Download the source rpm corresponding to the latest released RHEL build

  8. fedpkg import <full patch to source rpm>

    • For example: fedpkg import /tmp/pycairo-1.20.0-4.el9.src.rpm

  9. fedpkg commit -m "import from CentOS Stream srpm"

  10. git mv <package>.spec <package>-epel.spec

    • For example: git mv pycairo.spec pycairo-epel.spec

  11. fedpkg commit -m "rename spec file"

  12. Edit the spec file so it builds, but only produces the missing binaries

  13. Test build and test install your rpm, which ever way you like to do that

  14. fedpkg commit -m "Convert RHEL<version> <package> to <package>-epel with just <package>-devel subpackage"

    • For example: fedpkg commit -m "Convert RHEL9 pycairo to pycairo-epel with just python3-cairo-devel subpackage"

  15. fedpkg push

  16. fedpkg build

  17. fedpkg update

Missing-but-built spec examples

These examples should help you convert your RHEL spec file to a -epel spec file.

Header/top of spec

  • State where the original spec came from, and where to look to make sure it is in sync.

  • A variable for the original name of the package. It doesn’t have to be rhel_name, but keep it consistent.

    • Do a global replacement of %{name} to %{rhel_name} in your spec file.

  • Turn off debugsource.

# This spec file is derived from the RHEL9 pycairo spec file.  They should be kept
# in sync over time.
# https://gitlab.com/redhat/centos-stream/rpms/pycairo
%global rhel_name pycairo
%global _debugsource_template %{nil}

%prep

Add -n %{rhel_name}-%{version} to your setup. So the build doesn’t think the source is in <package>-epel-version.

%prep
%autosetup -p1 -n %{rhel_name}-%{version}

%package %description and %files

You need to add -n %{rhel_name}- to each of these.

%package -n %{rhel_name}-devel
%description -n %{rhel_name}-devel
%files -n %{rhel_name}-devel

Fix Requires:

Most -devel packages have a Requires: equal to the Name-Version-Release (NVR)

%package -n %{rhel_name}-devel
Requires: %{rhel_name}%{?_isa} = %{version}-%{release}

If this were a perfect world, you could leave your -epel package like that. But it’s not a perfect world, and there are many times you need to update your -epel package separate from the RHEL package being updated.

The following are two options. It is up to the -epel package maintainer to decide which is right for them, or perhaps do things your own way.

Remove release

If your -epel package only has some unchanging headers, you usually do not need to keep completely in step with the RHEL release, only the version. If that is the case, simply remove the -%{release} section.

%package -n %{rhel_name}-devel
Requires: %{rhel_name}%{?_isa} = %{version}
Rename release

If your -epel package has to be updated each time the RHEL package is updated, no matter what, one way to do this is with a %{rhel_release} that goes along with your %{rhel_name}. If you do this, your -epel release must be less than the RHEL release.

...
%global rhel_name pycairo
%global rhel_release 4
%global epel_release 1
...
Name: %{rhel_name}-epel
Release: 0.%{rhel_release}%{?dist}.%{epel_release}
...
%package -n %{rhel_name}-devel
Requires: %{rhel_name}%{?_isa} = %{version}-%{rhel_release}
...

ExcludeArch: (if needed)

Some sub-packages are only missing in some arches. If that is the case, then you should use ExcludeArch: to have your package only built on those arches you care about.

# This is only for non-x86/POWER architectures
ExcludeArch: %{ix86} x86_64 %{power64}

Remove files shipped in RHEL

At the end of the %install section, remove all the files you will not be shipping.

%install
%py3_install

# remove files shipped in RHEL
rm -rf %{buildroot}%{python3_sitearch}

Remove un-needed sections

  • Need to remove

    • %files

      • Remove all the %files sections you will not be shipping.

      • Make sure any file listed in those sections is removed in the %install section.

  • Optional remove

    • %package and %description

    • %prep, %post, and other scripts

    • %check

      • This really depends on what you are doing. If %check takes an hour, and all you need is a few headers, feel free to remove it. If the missing package has an actual program in it, leave it in.

      • When in doubt, leave %check in.

Missing un-built examples

These examples are for the Missing RHEL sub-packages/missing un-built sub-packages policy.

Want to help? Learn how to contribute to Fedora Docs ›