Thanks! I have missed that. And indeed the epel9 branch is affected as well. However not causing issues there due to epel9 and rhel9 using the same .dist. For my local tests I had .dist set to .el10.

While your proposed change fixes the issue, I think the following change IS even better in ensuring libev-devel and libev-libevent-devel Match:

-Requires:         %{rhel_name}-devel%{?_isa} = %{version}-%{release}
+Requires:         %{rhel_name}-devel%{?_isa} < %{version}-%(expr %{rhel_release} + 1)
+Requires:         %{rhel_name}-devel%{?_isa} >= %{version}-%{rhel_release}

This update has been unpushed.

The recommended way to do a ranged dependency is the with operator.

https://rpm.org/docs/4.20.x/manual/boolean_dependencies.html

It is also preferable to use the built in expression expansion syntax instead of shelling out to the expr command.

https://rpm.org/docs/4.20.x/manual/macros.html#expression-expansion

That would give you a requires like so:

Requires: (%{rhel_name}-devel%{?_isa} >= %{version}-%{rhel_release} with %{rhel_name}-devel%{?_isa} < %{version}-%[ %{rhel_release} + 1 ])

All that said, is it really necessary to match the libev-devel from CRB exactly? That puts you in a situation where a simple release bump of libev-devel for something innocuous causes libev-libevent-devel to no longer install. What I tend to do for my *-epel packages is set the requires to just be a matching version and ignore the release.

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

I did know about the with operator. However, it would never have occurred to me to use it for a ranged dependency. In my opinion, two separate requirements are much easier for a human to understand. The link you provided only introduces the with operator, but says nothing about it being recommended for a ranged dependency. Can you please provide a link to guidelines or similar where it says that it is recommended to use a with statement in that case? I hope to find further background information there.

Concerning the expression-expansion: I actually didn't know this. Thanks!

Concerning your question "All that said, is it really necessary to match the libev-devel from CRB exactly? " With this -epel package, I'm attempting to recreate the original package as closely as possible. This is a task doomed to failure from the start: A package should never exist as a source in two places and then being combined to form the entire package. The libev-libevent-devel subpackage of the original package has a very strict dependency on libev-devel by using Requires: %{name}-devel%{?_isa} = %{version}-%{release}. I have to assume that this very strict dependency is sensible and necessary. For the -epel package I can not have a requirement as strict - as seen previously - as .dist might differ between distributions. So I have three options now:

1. Using a requires as strict as the original by specifying: Requires: %{rhel_name}-devel%{?_isa} >= %{version}-%{rhel_release}.el10
2. Using a slightly less strict dependency by not taking .dist into account. The only possible way I know of to achieve that is using the range dependency.
3. Loosen the dependency even further and only require the same %{version}.

I honestly do not know which is the best. Number 2 seems to be the option that best mimics the original package without getting into too many issues.

Can you please provide a link to guidelines or similar where it says that it is recommended to use a with statement in that case?

I don't think we have it written in any guidelines, but it's explained in a bit more depth in the original bug and the corresponding issue that lead to the creation of the with operator. Basically, with enforces that all the operands are fulfilled by the same package. When you use multiple requires (or the and operator) the separate operands can be satisfied by different packages, which can really go off the rails when versioned compat packages are involved. The way you have it works now with just libev-devel present, it could break in the future if a libev5-devel package is introduced that also provides libev-devel(x86-64). In that case your >= requires would be satisfied by libev5-devel, and your < requires would be satisfied by libev-devel, and the build would fail because the packages conflict with each other and couldn't be installed at the same time.

I have to assume that this very strict dependency is sensible and necessary.

These type of dependencies between subpackages of the same build are usually just boilerplate. You can see this yourself if you run rpmdev-newspec libfoo. The version requirement is usually quite important to ensure software functionality, but the release requirement is mainly intended to forcibly keep the subpackages from the same build in sync. Since in this case the subpackages are not coming from the same build, it's impossible to keep them perfectly in sync, so in my opinion the release requirement does more harm than good.

I honestly do not know which is the best. Number 2 seems to be the option that best mimics the original package without getting into too many issues.

Method 2 that you went with is fine for now, but if/when libev gets a release bump your subpackages will no longer install. At that point I would advise you to consider switching to method 3.