multilib.bbclass: extend allarch recipes

This can fix do_rootfs and depends chaos when multilib, for example
ca-certificates is an allarch recipe:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "core2-32"
IMAGE_INSTALL_append = " ca-certificates"
$ bitbake ca-certificates
$ rpm -qpR tmp-glibc/deploy/rpm/noarch/ca-certificates-20170717-r0.noarch.rpm
[snip]
openssl
[snip]

It requires openssl, but lib32-openssl doesn't proivide it:
$ rpm -qp --provides tmp-glibc/deploy/rpm/core2_32/lib32-openssl-1.0.2l-r0.core2_32.rpm
lib32-openssl = 1.0.2l-r0

So openssl-1.0.2l-r0.core2_64.rpm would be installed when install
ca-certificates, e.g.:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "core2-32"
IMAGE_INSTALL_append = " ca-certificates"
$ bitbake lib32-core-image-minimal
The openssl-1.0.2l-r0.core2_64.rpm and other 64 bit packages are installed,
this is incorrect.

We have two solutions on this:
1) Let lib32-openssl provide openssl, but this would cause more problems when
   building since more than one providers for openssl.

Or

2) Extend allarch recipes, there would be ca-certificates-20170717-r0.noarch.rpm
   and lib32-ca-certificates-20170717-r0.noarch.rpm, then ca-certificates
   requires openssl, and lib32-ca-certificates requires lib32-openssl, the
   packages will be installed correctly, this is the best solution that I can
   find.

The problem has existed for years for deb and ipk (rpm did work since it didn't
use lib32-BPN in rpm filename before changed to dnf, for example, there was no
lib32-openssl.core2_32.rpm, but openssl.core2_32.rpm), this patch can fix the
problem for rpm, ipk and deb.

[YOCTO #12288]

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>

0 files changed, 0 insertions, 0 deletions