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.

  • fedpkg request-repo --exception <package>-epel

    • fedpkg request-repo --exception pycairo-epel

  • fedpkg request-branch --repo <package>-epel epel<version>

    • fedpkg request-branch --repo pycairo-epel epel9

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

  • Wait until you get an email saying the request is done

  • fedpkg clone <package>-epel ; cd <package>-epel

    • fedpkg clone pycairo-epel ; cd pycairo-epel

  • fedpkg retire "For epel only, not Fedora"

  • fedpkg switch-branch epel<version>

    • fedpkg switch-branch epel9

  • Download the source rpm corresponding to the latest released RHEL build

  • fedpkg import <full patch to source rpm>

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

  • fedpkg commit -m "import from CentOS srpm"

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

    • git mv pycairo.spec pycairo-epel.spec

  • fedpkg commit -m "rename spec file"

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

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

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

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

  • fedpkg push

  • fedpkg build

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

Put Examples and Tips Here