proposed recommendation - missing devel packages

[Troy Dawson]

I believe this is a recommendation, versus a policy.
I wanted to get people's thoughts on it, and if ya'll like it, put it in
the documentation.
----
In Red Hat Enterprise Linux (RHEL) 8, Red Hat decided to not ship all
packages that are built from RHEL spec files.  This will also be true of
RHEL 9, and possibly future RHEL releases.  These missing packages are
usually -devel packages and may impact an EPEL package build.
If your EPEL package is impacted by a missing -devel package, do the
following.

1 - Request the package be added to RHEL 8 and 9 CRB repository.
-- To initiate this process, please file a bug in
https://bugzilla.redhat.com and request it be added to RHEL 8 and 9. Report
the bug against the "CentOS Stream" version of the "Red Hat Enterprise
Linux 8" and/or "Red Hat Enterprise Linux 9" product.
-- Be sure to say that it is impacting an EPEL build, and which package it
is impacting.

2 - Create an epel package that only has the missing packages.
-- Be prepared to maintain this package as long as it is needed.
-- It is recommended that you name it <package>-epel
-- It is recommended that you add the epel-packaging-sig group as a
co-maintainer
-- It qualifies for an exception to the review process[1] so you can
request the repo with
--- fedpkg request-repo --exception <package>-epel
-- If you need help building this, ask for help.  We have some examples.

3 - When/If the missing package(s) are added to RHEL CRB, retire your -epel
package.

---
Sorry, this is a little rushed.  I wanted to get something out sooner,
rather than later.

Troy

[1] -
https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#...
- Third bullet point

[Kevin Fenzi]

On Thu, Jul 01, 2021 at 03:05:50PM -0700, Troy Dawson wrote:
> I believe this is a recommendation, versus a policy.
> I wanted to get people's thoughts on it, and if ya'll like it, put it in
> the documentation.
>
> In Red Hat Enterprise Linux (RHEL) 8, Red Hat decided to not ship all
> packages that are built from RHEL spec files.  This will also be true of
> RHEL 9, and possibly future RHEL releases.  These missing packages are
> usually -devel packages and may impact an EPEL package build.
> If your EPEL package is impacted by a missing -devel package, do the
> following.
>
> 1 - Request the package be added to RHEL 8 and 9 CRB repository.
> -- To initiate this process, please file a bug in
> https://bugzilla.redhat.com and request it be added to RHEL 8 and 9. Report
> the bug against the "CentOS Stream" version of the "Red Hat Enterprise
> Linux 8" and/or "Red Hat Enterprise Linux 9" product.
> -- Be sure to say that it is impacting an EPEL build, and which package it
> is impacting.
>
> 2 - Create an epel package that only has the missing packages.
> -- Be prepared to maintain this package as long as it is needed.
> -- It is recommended that you name it <package>-epel

--- It cannot be named <package> (ie, the same name as the rhel source
package name).
> -- It is recommended that you add the epel-packaging-sig group as a
> co-maintainer
> -- It qualifies for an exception to the review process[1] so you can
> request the repo with
> --- fedpkg request-repo --exception <package>-epel
> -- If you need help building this, ask for help.  We have some examples.

-- keep it in sync with the RHEL version, upgrade when they do.
> 3 - When/If the missing package(s) are added to RHEL CRB, retire your -epel
> package.
>
> Sorry, this is a little rushed.  I wanted to get something out sooner,
> rather than later.

Looks great to me aside the nitpicks above.

kevin

[Carl George]

This looks great so far to me.

Should we also encourage/require modifying the release to have a
leading `0.` so that it will upgrade cleanly when/if RHEL adds the
relevant subpackage?

On Thu, Jul 1, 2021 at 5:30 PM Kevin Fenzi  wrote:
> On Thu, Jul 01, 2021 at 03:05:50PM -0700, Troy Dawson wrote:
> > I believe this is a recommendation, versus a policy.
> > I wanted to get people's thoughts on it, and if ya'll like it, put it in
> > the documentation.
> >
> > In Red Hat Enterprise Linux (RHEL) 8, Red Hat decided to not ship all
> > packages that are built from RHEL spec files.  This will also be true of
> > RHEL 9, and possibly future RHEL releases.  These missing packages are
> > usually -devel packages and may impact an EPEL package build.
> > If your EPEL package is impacted by a missing -devel package, do the
> > following.
> >
> > 1 - Request the package be added to RHEL 8 and 9 CRB repository.
> > -- To initiate this process, please file a bug in
> > https://bugzilla.redhat.com and request it be added to RHEL 8 and 9. Report
> > the bug against the "CentOS Stream" version of the "Red Hat Enterprise
> > Linux 8" and/or "Red Hat Enterprise Linux 9" product.
> > -- Be sure to say that it is impacting an EPEL build, and which package it
> > is impacting.
> >
> > 2 - Create an epel package that only has the missing packages.
> > -- Be prepared to maintain this package as long as it is needed.
> > -- It is recommended that you name it <package>-epel
>
> --- It cannot be named <package> (ie, the same name as the rhel source
> package name).
> > -- It is recommended that you add the epel-packaging-sig group as a
> > co-maintainer
> > -- It qualifies for an exception to the review process[1] so you can
> > request the repo with
> > --- fedpkg request-repo --exception <package>-epel
> > -- If you need help building this, ask for help.  We have some examples.
>
> -- keep it in sync with the RHEL version, upgrade when they do.
> > 3 - When/If the missing package(s) are added to RHEL CRB, retire your -epel
> > package.
> >
> > Sorry, this is a little rushed.  I wanted to get something out sooner,
> > rather than later.
>
> Looks great to me aside the nitpicks above.
>
> kevin
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]...
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

and about missing binary packages Re: proposed recommendation - missing devel packages

[Sérgio Basto]

Hi,

Sorry, this may be a little Off-topic but we notice that lame package
from RHEL 8 (1) is not shipping lame package with binaries and in this
case lame-devel is provided along with lame-libs , can we apply the
same rules ? is completely a different situation ?

(1)
https://git.centos.org/rpms/lame/blob/c8/f/SPECS/lame.spec

On Thu, 2021-07-01 at 15:05 -0700, Troy Dawson wrote:
> I believe this is a recommendation, versus a policy.
> I wanted to get people's thoughts on it, and if ya'll like it, put it
> in the documentation.
>
> In Red Hat Enterprise Linux (RHEL) 8, Red Hat decided to not ship all
> packages that are built from RHEL spec files.  This will also be true
> of RHEL 9, and possibly future RHEL releases.  These missing packages
> are usually -devel packages and may impact an EPEL package build.
> If your EPEL package is impacted by a missing -devel package, do the
> following.
>
> 1 - Request the package be added to RHEL 8 and 9 CRB repository.  
> -- To initiate this process, please file a bug in
> https://bugzilla.redhat.com and request it be added to RHEL 8 and 9.
> Report the bug against the "CentOS Stream" version of the "Red Hat
> Enterprise Linux 8" and/or "Red Hat Enterprise Linux 9" product. 
> -- Be sure to say that it is impacting an EPEL build, and which package
> it is impacting.
>
> 2 - Create an epel package that only has the missing packages.
> -- Be prepared to maintain this package as long as it is needed.
> -- It is recommended that you name it <package>-epel
> -- It is recommended that you add the epel-packaging-sig group as a co-
> maintainer
> -- It qualifies for an exception to the review process[1] so you can
> request the repo with
> --- fedpkg request-repo --exception <package>-epel
> -- If you need help building this, ask for help.  We have some
> examples.
>
> 3 - When/If the missing package(s) are added to RHEL CRB, retire your -
> epel package.
>
> Sorry, this is a little rushed.  I wanted to get something out sooner,
> rather than later.
>
> Troy
>
> [1] -
> https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#...
>   - Third bullet point

and about missing binary packages Re: proposed recommendation - missing devel packages

[Carl George]

Yes, this would also apply to that scenario.  You can create a
lame-epel package that has a lame subpackage, as long as none of the
files conflict with lame-devel and lame-libs from RHEL8.  You would
also want to relax the requirement on lame-libs by removing the
%{release}, so that way you can bump the release on the epel package
and still have the requirement satisfied by the RHEL lame-libs.

-Requires:       %{name}-libs = %{version}-%{release}
+Requires:       %{name}-libs = %{version}

On Thu, Jul 1, 2021 at 5:31 PM Sérgio Basto  wrote:
> Hi,
>
> Sorry, this may be a little Off-topic but we notice that lame package
> from RHEL 8 (1) is not shipping lame package with binaries and in this
> case lame-devel is provided along with lame-libs , can we apply the
> same rules ? is completely a different situation ?
>
> (1)
> https://git.centos.org/rpms/lame/blob/c8/f/SPECS/lame.spec
>
> On Thu, 2021-07-01 at 15:05 -0700, Troy Dawson wrote:
> > I believe this is a recommendation, versus a policy.
> > I wanted to get people's thoughts on it, and if ya'll like it, put it
> > in the documentation.
> >
> > In Red Hat Enterprise Linux (RHEL) 8, Red Hat decided to not ship all
> > packages that are built from RHEL spec files.  This will also be true
> > of RHEL 9, and possibly future RHEL releases.  These missing packages
> > are usually -devel packages and may impact an EPEL package build.
> > If your EPEL package is impacted by a missing -devel package, do the
> > following.
> >
> > 1 - Request the package be added to RHEL 8 and 9 CRB repository.
> > -- To initiate this process, please file a bug in
> > https://bugzilla.redhat.com and request it be added to RHEL 8 and 9.
> > Report the bug against the "CentOS Stream" version of the "Red Hat
> > Enterprise Linux 8" and/or "Red Hat Enterprise Linux 9" product.
> > -- Be sure to say that it is impacting an EPEL build, and which package
> > it is impacting.
> >
> > 2 - Create an epel package that only has the missing packages.
> > -- Be prepared to maintain this package as long as it is needed.
> > -- It is recommended that you name it <package>-epel
> > -- It is recommended that you add the epel-packaging-sig group as a co-
> > maintainer
> > -- It qualifies for an exception to the review process[1] so you can
> > request the repo with
> > --- fedpkg request-repo --exception <package>-epel
> > -- If you need help building this, ask for help.  We have some
> > examples.
> >
> > 3 - When/If the missing package(s) are added to RHEL CRB, retire your -
> > epel package.
> >
> > Sorry, this is a little rushed.  I wanted to get something out sooner,
> > rather than later.
> >
> > Troy
> >
> > [1] -
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#...
> > Third bullet point
>
> --
> Sérgio M. B.
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/[e-mail]...
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Orion Poplawski]

On 7/1/21 4:05 PM, Troy Dawson wrote:
> I believe this is a recommendation, versus a policy.
> I wanted to get people's thoughts on it, and if ya'll like it, put it in 
> the documentation.
>
> In Red Hat Enterprise Linux (RHEL) 8, Red Hat decided to not ship all 
> packages that are built from RHEL spec files.  This will also be true of 
> RHEL 9, and possibly future RHEL releases.  These missing packages are 
> usually -devel packages and may impact an EPEL package build.
> If your EPEL package is impacted by a missing -devel package, do the 
> following.
>
> 1 - Request the package be added to RHEL 8 and 9 CRB repository.
> -- To initiate this process, please file a bug in 
> https://bugzilla.redhat.com https://bugzilla.redhat.com and request it 
> be added to RHEL 8 and 9. Report the bug against the "CentOS Stream" 
> version of the "Red Hat Enterprise Linux 8" and/or "Red Hat Enterprise 
> Linux 9" product.
> -- Be sure to say that it is impacting an EPEL build, and which package 
> it is impacting.
>
> 2 - Create an epel package that only has the missing packages.
> -- Be prepared to maintain this package as long as it is needed.
> -- It is recommended that you name it <package>-epel
> -- It is recommended that you add the epel-packaging-sig group as a 
> co-maintainer
> -- It qualifies for an exception to the review process[1] so you can 
> request the repo with
> --- fedpkg request-repo --exception <package>-epel
> -- If you need help building this, ask for help.  We have some examples.
>
> 3 - When/If the missing package(s) are added to RHEL CRB, retire your 
> -epel package.
>
> Sorry, this is a little rushed.  I wanted to get something out sooner, 
> rather than later.
>
> Troy

So, I've decided to try this with utf8proc.  I've requested the 
utf8proc-epel package and now requested an epel8 branch (and will retire 
the rawhide branch).

These are the changes I have made, does this seem correct?  Notes on 
changes:

* We are not shipping binaries, so need to disable the debug package
* Need to change Name and %{name}
* Need to explicitly name the devel package
* Need to use relative Requires for the main package.  Both to allow 
RHEL to update and (in this case) to deal with module release tags
* Remove the files installed for the main package
* Remove %files and %post* for the main package
* Add %changelog entry

--- SPECS/utf8proc.spec 2021-09-22 21:24:59.304665646 -0600
+++ /export/home/orion/fedora/utf8proc-epel/utf8proc-epel.spec 
2021-09-22 21:32:01.568719918 -0600
@@ -1,11 +1,13 @@
+%global debug_package %{nil}
+
  Summary: Library for processing UTF-8 encoded Unicode strings
-Name:    utf8proc
+Name:    utf8proc-epel
  Version: 2.1.1
  Release: 5%{?dist}
  License: Unicode and MIT
  Group:   System Environment/Libraries
  URL:     http://julialang.org/utf8proc/
-Source: 
https://github.com/JuliaLang/utf8proc/archive/v%%7Bversion%7D.tar.gz#/%%7Bna...
+Source: 
https://github.com/JuliaLang/utf8proc/archive/v%%7Bversion%7D/utf8proc-%%7Bv...
  BuildRequires: gcc

%description
@@ -21,12 +23,12 @@

This package only contains the C library.

-%package devel
+%package -n utf8proc-devel
  Summary:  Header files, libraries and development documentation for 
%{name}
  Group:    Development/Libraries
-Requires: %{name}%{?_isa} = %{version}-%{release}
+Requires: utf8proc%{?_isa} >= %{version}-%{release}

-%description devel
+%description -n utf8proc-devel
  Contains header files for developing applications that use the %{name}
  library.

@@ -35,7 +37,7 @@
  strings, unless you want to allocate memory yourself.

%prep
-%setup -qn %{name}-%{version}
+%setup -qn utf8proc-%{version}
  # Disable slow tests and tests which require network access
  sed -i '/-C bench/d;/\ttest.* data/d' Makefile
  touch data/NormalizationTest.txt data/GraphemeBreakTest.txt
  touch data/NormalizationTest.txt data/GraphemeBreakTest.txt
@@ -50,19 +52,16 @@
  %install
  make install DESTDIR=%{buildroot} prefix=%{_prefix} 
includedir=%{_includedir} libdir=%{_libdir}
  rm %{buildroot}%{_libdir}/libutf8proc.a
+rm %{buildroot}%{_libdir}/libutf8proc.so.*

-%post -p /sbin/ldconfig
-%postun -p /sbin/ldconfig
-
-%files
-%doc LICENSE.md NEWS.md README.md
-%{_libdir}/libutf8proc.so.*
-
-%files devel
+%files -n utf8proc-devel
  %{_includedir}/utf8proc.h
  %{_libdir}/libutf8proc.so

%changelog
+* Wed Sep 22 2021 Orion Poplawski  - 2.1.1-5
+- EPEL -devel only package
+
  * Mon Aug 05 2019 Lubos Uhliarik  - 2.1.1-5
  - Resolves: #1696354 - Ensure modular RPM upgrade path

Comments?

[Troy Dawson]

That looks great, and very close to what I've done.
I have a couple of variations.
I think the biggest is that I set a variable called rhel_name and then
change %{name} to %{rhel_name}.  It looks like you only had two instances
of %{name} but I've had a couple with many instances of it, and this makes
it easier.
The second is that I usually put a link to the upstream spec file, in
comments.  I use the CentOS Stream git repo, because it's publicly
available.  This is mainly for me, cuz I never know where to find them.
So, this is at the top of my spec files.

# This spec file is derived from the RHEL8 spec file.
#   They should be kept in sync over time.
# https://git.centos.org/rpms/libpinyin/blob/c8/f/SPECS/libpinyin.spec
%global rhel_name libpinyin
%global _debugsource_template %{nil}

But, that's just my preferences.  I think yours should be fine.

I'm thinking we might want to break this out from a question in the FAQ to
it's own page.

Troy

On Wed, Sep 22, 2021 at 8:42 PM Orion Poplawski  wrote:
> On 7/1/21 4:05 PM, Troy Dawson wrote:
> > I believe this is a recommendation, versus a policy.
> > I wanted to get people's thoughts on it, and if ya'll like it, put it in
> > the documentation.
> >
> > In Red Hat Enterprise Linux (RHEL) 8, Red Hat decided to not ship all
> > packages that are built from RHEL spec files.  This will also be true of
> > RHEL 9, and possibly future RHEL releases.  These missing packages are
> > usually -devel packages and may impact an EPEL package build.
> > If your EPEL package is impacted by a missing -devel package, do the
> > following.
> >
> > 1 - Request the package be added to RHEL 8 and 9 CRB repository.
> > -- To initiate this process, please file a bug in
> > https://bugzilla.redhat.com https://bugzilla.redhat.com and request
>
> it
> > be added to RHEL 8 and 9. Report the bug against the "CentOS Stream"
> > version of the "Red Hat Enterprise Linux 8" and/or "Red Hat Enterprise
> > Linux 9" product.
> > -- Be sure to say that it is impacting an EPEL build, and which package
> > it is impacting.
> >
> > 2 - Create an epel package that only has the missing packages.
> > -- Be prepared to maintain this package as long as it is needed.
> > -- It is recommended that you name it <package>-epel
> > -- It is recommended that you add the epel-packaging-sig group as a
> > co-maintainer
> > -- It qualifies for an exception to the review process[1] so you can
> > request the repo with
> > --- fedpkg request-repo --exception <package>-epel
> > -- If you need help building this, ask for help.  We have some examples.
> >
> > 3 - When/If the missing package(s) are added to RHEL CRB, retire your
> > -epel package.
> >
> > Sorry, this is a little rushed.  I wanted to get something out sooner,
> > rather than later.
> >
> > Troy
>
> So, I've decided to try this with utf8proc.  I've requested the
> utf8proc-epel package and now requested an epel8 branch (and will retire
> the rawhide branch).
>
> These are the changes I have made, does this seem correct?  Notes on
> changes:
> We are not shipping binaries, so need to disable the debug package
> Need to change Name and %{name}
> Need to explicitly name the devel package
> Need to use relative Requires for the main package.  Both to allow
>
> RHEL to update and (in this case) to deal with module release tags
> Remove the files installed for the main package
> Remove %files and %post* for the main package
> Add %changelog entry
>
> --- SPECS/utf8proc.spec 2021-09-22 21:24:59.304665646 -0600
> +++ /export/home/orion/fedora/utf8proc-epel/utf8proc-epel.spec
> 2021-09-22 21:32:01.568719918 -0600
> @@ -1,11 +1,13 @@
> +%global debug_package %{nil}
> Summary: Library for processing UTF-8 encoded Unicode strings
>
> -Name:    utf8proc
> +Name:    utf8proc-epel
>   Version: 2.1.1
>   Release: 5%{?dist}
>   License: Unicode and MIT
>   Group:   System Environment/Libraries
>   URL:     http://julialang.org/utf8proc/
> -Source:
>
> https://github.com/JuliaLang/utf8proc/archive/v%%7Bversion%7D.tar.gz#/%%7Bna...
> +Source:
>
> https://github.com/JuliaLang/utf8proc/archive/v%%7Bversion%7D/utf8proc-%%7Bv...
>   BuildRequires: gcc
>
> %description
> @@ -21,12 +23,12 @@
>
> This package only contains the C library.
>
> -%package devel
> +%package -n utf8proc-devel
>   Summary:  Header files, libraries and development documentation for
> %{name}
>   Group:    Development/Libraries
> -Requires: %{name}%{?_isa} = %{version}-%{release}
> +Requires: utf8proc%{?_isa} >= %{version}-%{release}
>
> -%description devel
> +%description -n utf8proc-devel
>   Contains header files for developing applications that use the %{name}
>   library.
>
> @@ -35,7 +37,7 @@
>   strings, unless you want to allocate memory yourself.
>
> %prep
> -%setup -qn %{name}-%{version}
> +%setup -qn utf8proc-%{version}
>   # Disable slow tests and tests which require network access
>   sed -i '/-C bench/d;/\ttest.* data/d' Makefile
>   touch data/NormalizationTest.txt data/GraphemeBreakTest.txt
>   touch data/NormalizationTest.txt data/GraphemeBreakTest.txt
> @@ -50,19 +52,16 @@
>   %install
>   make install DESTDIR=%{buildroot} prefix=%{_prefix}
> includedir=%{_includedir} libdir=%{_libdir}
>   rm %{buildroot}%{_libdir}/libutf8proc.a
> +rm %{buildroot}%{_libdir}/libutf8proc.so.*
>
> -%post -p /sbin/ldconfig
> -%postun -p /sbin/ldconfig
>
> -%files
> -%doc LICENSE.md NEWS.md README.md
> -%{_libdir}/libutf8proc.so.*
>
> -%files devel
> +%files -n utf8proc-devel
>   %{_includedir}/utf8proc.h
>   %{_libdir}/libutf8proc.so
>
> %changelog
> +* Wed Sep 22 2021 Orion Poplawski  - 2.1.1-5
> +- EPEL -devel only package
> Mon Aug 05 2019 Lubos Uhliarik  - 2.1.1-5
> Resolves: #1696354 - Ensure modular RPM upgrade path
>
> Comments?
>
> --
> Orion Poplawski
> he/him/his - surely the least important thing about me
> Manager of NWRA Technical Systems          720-772-5637
> NWRA, Boulder/CoRA Office             FAX: [phone]
> 3380 Mitchell Lane                       [e-mail]
> Boulder, CO 80301                 https://www.nwra.com/
>
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure

[Orion Poplawski]

On 9/23/21 7:28 AM, Troy Dawson wrote:
> That looks great, and very close to what I've done.
> I have a couple of variations.
> I think the biggest is that I set a variable called rhel_name and then 
> change %{name} to %{rhel_name}.  It looks like you only had two 
> instances of %{name} but I've had a couple with many instances of it, 
> and this makes it easier.
> The second is that I usually put a link to the upstream spec file, in 
> comments.  I use the CentOS Stream git repo, because it's publicly 
> available.  This is mainly for me, cuz I never know where to find them.
> So, this is at the top of my spec files.
>
> # This spec file is derived from the RHEL8 spec file.
> #   They should be kept in sync over time.
> # https://git.centos.org/rpms/libpinyin/blob/c8/f/SPECS/libpinyin.spec 
> https://git.centos.org/rpms/libpinyin/blob/c8/f/SPECS/libpinyin.spec
> %global rhel_name libpinyin
> %global _debugsource_template %{nil}
>
> But, that's just my preferences.  I think yours should be fine.

Thanks, good ideas.
> I'm thinking we might want to break this out from a question in the FAQ 
> to it's own page.

+1
> Troy

[Miro Hrončok]

On 23. 09. 21 5:41, Orion Poplawski wrote:
> -Requires: %{name}%{?_isa} = %{version}-%{release}
> +Requires: utf8proc%{?_isa} >= %{version}-%{release}

I'd assume that anybody (even you) might need to rebuild this package in EPEL 
at any time for various reasons and %{release} might be larger than the RHEL 
package release. This >= requireement will break.

Also, if the RHEL version gets updated to e.g. 2.1.2 (unlikely, but not 
impossible), the EPEL devel package will still be able to be installed, which 
is probably undesired.

If you don't need to follow RHEL's release number that much, I suggest to do:

Requires: utf8proc%{?_isa} = %{version}

And if you do, I suggest to do:

%global rhel_release 5
Requires: (utf8proc%{?_isa} = %{version} with utf8proc%{?_isa} >= 
%{version}-%{rhel_release})

You could even incorporate the RHEL's release to the EPEL's release, if you 
feel like it:

%global rhel_release 5
%global base_release 1

Release:  %{rhel_release}.%{base_release}%{?dist}

Side note: I also suggest to BuildRequire the runtime requirement (sans 
%{?_isa}) and track the package in Koschei. That way, you can get a 
notification if the requirement was broken by an RHEL update and the EPEL 
package needs to be updated as well.

[Orion Poplawski]

On 9/23/21 9:00 AM, Miro Hrončok wrote:
> On 23. 09. 21 5:41, Orion Poplawski wrote:
> > -Requires: %{name}%{?_isa} = %{version}-%{release}
> > +Requires: utf8proc%{?_isa} >= %{version}-%{release}
>
> I'd assume that anybody (even you) might need to rebuild this package in 
> EPEL at any time for various reasons and %{release} might be larger than 
> the RHEL package release. This >= requireement will break.
>
> Also, if the RHEL version gets updated to e.g. 2.1.2 (unlikely, but not 
> impossible), the EPEL devel package will still be able to be installed, 
> which is probably undesired.
>
> If you don't need to follow RHEL's release number that much, I suggest 
> to do:
>
> Requires: utf8proc%{?_isa} = %{version}
>
> And if you do, I suggest to do:
>
> %global rhel_release 5
> Requires: (utf8proc%{?_isa} = %{version} with utf8proc%{?_isa} >= 
> %{version}-%{rhel_release})
>
> You could even incorporate the RHEL's release to the EPEL's release, if 
> you feel like it:
>
> %global rhel_release 5
> %global base_release 1
>
> Release:  %{rhel_release}.%{base_release}%{?dist}
>
> Side note: I also suggest to BuildRequire the runtime requirement (sans 
> %{?_isa}) and track the package in Koschei. That way, you can get a 
> notification if the requirement was broken by an RHEL update and the 
> EPEL package needs to be updated as well.

Thanks, good ideas!