Why does bind9-next-devel provide bind-devel ?
I don't understand that.

It has the potential to have conflicts. Why even have it?

Very simple example:
RHEL 9 machine doesn't have CRB enabled. They try to install bind-devel. Conflict hit.

bind-devel might be required by bind-dyndb-ldap package and the bind9-next-devel provides required headers. But bind-dyndb-ldap would not compile with this version at the moment and no other package I know requires bind-devel.

Not sure this is valid example. dnf install bind-devel is supposed to fail without CRB. It still fails, but with a different message. I guess we do not have epel-CRB repository, where it could be placed instead. Not sure we should solve error on the user's side somehow.

But yes, Provides: bind-devel can be removed. It obviously has to conflict with it, it provides slightly different files. Not sure we can BuildRequires: (bind-devel or bind9-next-devel) in bind-dyndb-ldap instead, once the source is modified to compile.

It may provide headers necessary to compile DLZ modules from source, but I think only Samba has DLZ module outside bind9 distribution and it uses bundled header instead anyway.

OK, I think I'm seeing the problem.
Although bind9-next has a completely different name, all of it's files are the same names as bind, with possibly a few exceptions.

In EPEL, if it conflicts with RHEL files, the answer isn't even up for debate. It's a big no, we do not allow that.
If you need it built for RHEL, then COPR is the correct place to go, not EPEL.

Relevant section of EPEL policy:

EPEL packages should only enhance and never disturb the Enterprise Linux distributions they were built for. Thus packages from EPEL should never replace packages from the target base distribution.

https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy

As best I can recall, this has traditionally be interpreted as:

• no obsoleting RHEL packages
• no explicit conflicts with RHEL packages
• no implicit (file) conflicts with RHEL packages
• no providing a RHEL package name

Basically any possible way that it could disrupt the experience of using RHEL with EPEL enabled is not allowed. We could probably stand to expand on the policy to be clear about these scenarios.

We discussed this at today's EPEL Steering Committee meeting. We voted on allowing this package in its current state, with a final tally of 0 yes and 6 no. For this package to be allowed under the policy, it would need to no longer provide the RHEL package names, and would need to rename or relocate all files that conflict with files in RHEL packages. If this is not feasible, COPR is probably a better fit for this package.

Thank you for bringing this up, as we did agree that the policy needs to be more clear about what is allowed and what is meant by "only enhance and never disturb". We'll be working on improving that soon.

Note: This package doesn't follow the Fedora naming guidelines for multiple packages with the same base name. Based on that, this package should probably be renamed to bind9.19. Those guidelines do mention that using a hyphen followed by a descriptive suffix is allowed, but specifically cautions against using strings like "latest" which can be misleading. If you do plan to adjust the package to be allowed in EPEL, it would probably make sense to do the rename to bind9.19 first.

bind upstream has changed to bind9 repository name. It is kept to bind just for backward compatibility and because changing would be a lot of work without any visible advantage. So I made the new base name bind9, even when the original package remains bind. And suffix -next were proposed on upstream discussion and I like it. Unlike bind9.19, it can stay even after release of stable bind 9.20 and moving development version to bind9.21, which would require new review again. Unlike latest it is clear it is upcoming (unstable) version, while it is still reasonably short. I think it matches multiple packages with the same name,

I have checked openssl3 example and indeed it does not create any conflict. I am not sure it is feasible for bind9-next. It would require own SELinux rules and alternative store for data. I will keep it on COPR for now.