https://bugzilla.redhat.com/show_bug.cgi?id=1885430
--- Comment #10 from giovanni.cabiddu(a)intel.com ---
I uploaded a new version of the SPEC and the RPM:
Spec URL:
https://raw.githubusercontent.com/intel/qatlib/v20_08/rpm/qatlib.spec
SRPM URL:
https://raw.githubusercontent.com/intel/qatlib/v20_08/rpm/qatlib-20.08.0-...
Yes please, the guidelines are clear here. "If the bundled
package also exists separately in the distribution, use the name of that package."
Use `Provides: bundled(openssl) = 1.1.1c`. The idea is that if there is a vulnerability
discovered in a package, we can query for everything that provides it as a bundled
library. That only works when we standardize on a name so we don't have to query for
every possible variation or sub-library of that package.
Done.
I'm not sure I follow. Those are provided by the system openssl
library, not by qatengine. Where does it become circular? If it's debundled, the
build order for the distribution would be openssl, qatlib, then qatengine.
The
dependency is a run time, if qatlib uses the OpenSSL EVP API. In that case
we would have:
app -> openssl:libcrypto_EVP -> qat_engine -> qat_lib ->
openssl:libcrypto_EVP -> qat_engine -> qat_lib -> REPEAT
We resolved it by linking against OpenSSL/libcrypto and using the lower level
(public) crypto APIs for the algorithms we need. This change is included in the
next release.
This will work for now, however we have to re-think at the approach for the
future since for OpenSSL 3.0 those APIs are marked as DEPRECATED.
E.g.
https://github.com/openssl/openssl/blob/master/include/openssl/aes.h#L51
That's odd, because qatengine got permission to remove their
license header (bug 1885495 comment 10). If the spec file will be under the MIT license
(the Fedora default for spec files), then the comment header is just noise and needs to be
removed to improve legibility. To be clear, the qatlib.spec.in file in the upstream repo
can keep the header, we're only discussing the spec file that will be imported into
Fedora package sources.
I checked again and the guideline is to still leave the
license on the file. In
order to address the noise/visual clutter in the file we replaced the full
header with the SPDX License Identifier: `# SPDX-License-Identifier: MIT`
Is this ok?
The latter. There are many upstreams who don't test on
alternative architectures. Fedora basically is their alternative arch testing and QA
(which works better when there is an upstream test suite to run in %check). Unless it has
been established as fact that the software doesn't compile, build, or work on an
architecture, the package should build for that architecture.
Thanks. I haven't
run the build yet any alternative architectures. Is it
something I have to do? If yes, which architectures should I try?
--
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component