On 9/25/19 11:13 AM, George McCollister wrote:
On Wed, Sep 25, 2019 at 11:08 AM Mark Hatle
<[email protected]> wrote:

On 9/25/19 6:52 AM, George McCollister wrote:
Set OPENSSL_ENGINES to the path where engines are actually installed.

Signed-off-by: George McCollister <[email protected]>
---
  meta/recipes-connectivity/openssl/openssl_1.1.1d.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb 
b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
index 072f727e0b..8819e19ec4 100644
--- a/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
+++ b/meta/recipes-connectivity/openssl/openssl_1.1.1d.bb
@@ -148,7 +148,7 @@ do_install_append_class-native () {
           OPENSSL_CONF=${libdir}/ssl-1.1/openssl.cnf \
           SSL_CERT_DIR=${libdir}/ssl-1.1/certs \
           SSL_CERT_FILE=${libdir}/ssl-1.1/cert.pem \
-         OPENSSL_ENGINES=${libdir}/ssl-1.1/engines
+         OPENSSL_ENGINES=${libdir}/engines-1.1

Is this a bug in the openssl recipe (it's placing engines in the wrong place),
or a bug in the recipes providing acceleration engines and THEY are going into
the wrong place?

This recipe installs:
packages-split/openssl-engines/usr/lib/engines-1.1/afalg.so
packages-split/openssl-engines/usr/lib/engines-1.1/padlock.so
packages-split/openssl-engines/usr/lib/engines-1.1/capi.so

libp11 in meta-oe installs these:
packages-split/libp11/usr/lib/engines-1.1
packages-split/libp11/usr/lib/engines-1.1/pkcs11.so
packages-split/libp11-dev/usr/lib/engines-1.1
packages-split/libp11-dev/usr/lib/engines-1.1/libpkcs11.so


The ssl-1.1/engines makes more sense to me..  as /usr/lib/engines-1.1 obscures
that they are OpenSSL related.

I don't have a strong opinion either way but ssl-1.1/engines does make
a bit more sense.
Debian appears to install them in engines-1.1 though:
  https://packages.debian.org/buster/amd64/libssl1.1/filelist

I do need this fixed in warrior though and wonder if anyone would
gripe about changing where they are installed post release.

How shall we proceed? Does anyone else want to chime in?


Using /usr/lib/<package> is known jargon and lets use it. I think doing it the way other distros are doing it and how upstream defaults are is also helpful. it reduced one more thing to worry about. Release branches should not be an issue as long as we have them packages in same output package.


--Mark

  }

  do_install_append_class-nativesdk () {


--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

-George


--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Reply via email to