From an EPEL policy perspective, it would make more sense to start by submitting the 'intel-quatengine' to Fedora first (either by the package review process or as a PR to the quatengine package if possible).

Or at least that's what I remember about it

This cannot be done as long as it would create conflicts with the qatengine package in RHEL.

cc: @carlwgeorge

Yes we know this, that's why we're thinking to use "Conflicts" to solve the issue

cc: @vladis

As a general rule, packages in EPEL are not allowed to conflict with RHEL packages in name, file paths, or explicit Conflicts tags.

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

If the end goal is to enable features in RHEL's qatengine, a better approach would be to propose these changes as pull requests, first to the Fedora package and then later to the CentOS.

https://src.fedoraproject.org/rpms/qatengine
https://gitlab.com/redhat/centos-stream/rpms/qatengine

If these new features are not considered ready for Fedora, CentOS, or RHEL, then they are inappropriate for EPEL as well, and would make more sense in a COPR repo.

https://copr.fedorainfracloud.org/

In any event, using a name like intel-qatengine would be really confusing. Both would be related to "Intel QuickAssist Technology", so it would not be obvious to users what the difference between qatengine and intel-qatengine would be.

Hi as mentioned in the previous comment, this is not something we can do.

Hi, I'm Vladis from the Red Hat and I'm the maintainer of qatengine in RHEL.

The problem with intel-qatengine is that it implements certain crypto algorithms in software, which are also implemented in openssl (or something alike). RHEL cannot have this algorithms implemented in RHEL's version of qatengine because: 1) these algos will require a FIPS certification, made for a significant amount of money 2) this is not possible, as this is a RHEL rule to have a single implementation of a given crypto algo (in openssl, in this case).

this is why we require a separate Fedora and EPEL (but not RHEL) package intel-qatengine, conflicting with a "regular" qatengine for customers who do not care about FIPS certifications.

can you please create the "intel-qatengine" repo for Fedora and EPEL? we need this for continued business relations between Red Hat and Intel.

This isn't how things work. Fedora has a process for adding new packages: You must submit a review, get it reviewed and approved, and then automation adds it via a request. releng doesn't add arbitrary packages just because someone wants them.

https://docs.fedoraproject.org/en-US/package-maintainers/New_Package_Process_for_Existing_Contributors/

That said, I agree with @carlgeorge that 'intel-qatengine' would be confusing. I urge you to work with the EPEL folks to come up with some solution for your needs here... perhaps a qatengine-epel would be more workable? or a 'qatengine-accelerated' or something (but it would have to not conflict with the RHEL package.

This ticket isn't the right venue for it, but I agree with @kevin that more discussion is needed so we can understand the details here. Ideally @aekoroglu and @vladis will join us in the EPEL matrix room to discuss this interactively.

https://matrix.to/#/#epel:fedoraproject.org

Starting in COPR is still probably the correct first step. That will give us a clear picture of the changes needed to the qatengine spec file to enable software acceleration, and will help us make recommendations that work within the boundaries of Fedora and EPEL policy.

ok, i'm out of ideas then. let me add that (after checking qatengine.spec carefully) it looks like it is already has the mentioned software algos available (which are just disabled for RHEL) and no changes to qatengine is needed:

[ qatengine.spec ]
%if !0%{?rhel}
BuildRequires:  intel-ipp-crypto-mb-devel >= 1.0.6
BuildRequires:  intel-ipsec-mb-devel >= 1.3.0
BuildRequires:  openssl
%endif
...
%if !0%{?rhel}
# Enable QAT_HW & QAT_SW Co-existence acceleration
%configure --enable-qat_sw
%else
# QAT_HW only acceleration for RHEL
%configure
%endif

with this i do not see that a COPR build is needed, as the package is already built for rawhide, f39, f38, etc. do you mean that Intel can just build qatengine for EPEL9? in this case i do not understand how we can resolve a conflict in RHEL9 if both regular RHEL9 and EPEL9 repos are enabled (thus having both versions of qatengine available).

ok, i'm out of ideas then. let me add that (after checking qatengine.spec carefully) it looks like it is already has the mentioned software algos available (which are just disabled for RHEL) and no changes to qatengine is needed:

[ qatengine.spec ]
%if !0%{?rhel}
BuildRequires:  intel-ipp-crypto-mb-devel >= 1.0.6
BuildRequires:  intel-ipsec-mb-devel >= 1.3.0
BuildRequires:  openssl
%endif
...
%if !0%{?rhel}
# Enable QAT_HW & QAT_SW Co-existence acceleration
%configure --enable-qat_sw
%else
# QAT_HW only acceleration for RHEL
%configure
%endif

with this i do not see that a COPR build is needed, as the package is already built for rawhide, f39, f38, etc. do you mean that Intel can just build qatengine for EPEL9? in this case i do not understand how we can resolve a conflict in RHEL9 if both regular RHEL9 and EPEL9 repos are enabled (thus having both versions of qatengine available).

.

Thank you for pointing out that the necessary changes are already conditionalized in the spec file. That shows me what I was initially looking for from a COPR build. A COPR with these changes would still be useful for anyone that wants to immediately use this on RHEL, as they likely can't install the Fedora packages directly.

do you mean that Intel can just build qatengine for EPEL9?

No. I'm honestly puzzled as to how you could draw that conclusion from anything I said. Not only would it be a policy violation, but even requesting an epel9 branch for that package in dist-git will fail.

in this case i do not understand how we can resolve a conflict in RHEL9 if both regular RHEL9 and EPEL9 repos are enabled (thus having both versions of qatengine available).

EPEL stands for Extra Packages for Enterprise Linux. Right there in the name it describes the scope of providing extra packages. Providing replacement conflicting packages with different configure flags is allowed in COPR and CentOS SIGs such as Hyperscale, but not in EPEL.