There is a failure to build lib32-meta-toolchain:
...
|ERROR: lib32-packagegroup-core-standalone-sdk-target not found in the base
feeds (qemux86_64 x86 noarch any all).
...

In package_manager.py, the variable 'DEFAULTTUNE_virtclass-multilib-lib32'
is used to process multilib image/toolchain. But for the build of lib32-
meta-toolchain, the value of 'DEFAULTTUNE_virtclass-multilib-lib32' is
deleted. In 'bitbake lib32-meta-toolchain -e', we got:
...
|# $DEFAULTTUNE_virtclass-multilib-lib32 [2 operations]
|#   set? /home/jiahongxu/yocto/build-20141010-yocto/conf/local.conf:237
|#     "x86"
|#   del data_smart.py:406 [finalize]
|#     ""
|# pre-expansion value:
|#   "None"
...

The commit 899d45b90061eb3cf3e71029072eee42cd80930c in oe-core deleted
it at DataSmart.finalize
...
Author: Richard Purdie <richard.purdie@linuxfoundation.org>
Date:   Tue May 31 23:52:50 2011 +0100

    bitbake/data_smart: Change overrides behaviour to remove
       expanded variables from the datastore
...

We add an internal variable 'DEFAULTTUNE_ML_<multilib>', assign it with the
value of 'DEFAULTTUNE_virtclass-multilib-lib32' before deleting.

For rpm backend in package_manager.py, we use DEFAULTTUNE_virtclass-multilib
-lib32 first, if it is not available, and try to use DEFAULTTUNE_ML_<multilib>

[YOCTO #6842]

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

While building multilib extended images such as libXX-core-image-minimal,
the WORKDIR has the same dir with the building of core-image-minimal.

$ ls tmp/work/qemux86_64-poky-linux/ -al
...
drwxrwxr-x  3 jiahongxu jiahongxu 4096 Oct 13 16:01 core-image-minimal
drwxrwxr-x  3 jiahongxu jiahongxu 4096 Oct 16 11:11 lib32-core-image-minimal
...

While image class is inherited, it did not assign OVERRIDES with
'virtclass-multilib-libXXX', so the reason is variable TARGET_VENDOR was
not override for multilib in that situation.

It refers what did for PN and MLPREFIX, and manually do the multilib
override for TARGET_VENDOR in RecipePreFinalise handler.

[YOCTO #6844]

Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Now that all licenses are canonicalised to SPDX names when processing, we need
to rename the whitelists to the match.

[RP: Fixed up multilib.bbclass too]

Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Multilib QA warning was observed, as follows:
------
WARNING: Multilib QA Issue: lib32-oprofile package lib32-oprofile -
suspicious values 'kernel-vmlinux' in RRECOMMENDS
------

The package starting with 'kernel-vmlinux' should be ok with multilib QA
checking.

Signed-off-by: Ming Liu <ming.liu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

If we don't do this, systemd.bbclase will complain to unable to find multilib
packages since PACKAGES is expand with mlprefix, but SYSTEMD_PACKAGES is not,
like in ntp.inc:

    $grep PACKAGES meta-oe/meta-networking/recipes-support/ntp/ntp.inc
    PACKAGES += "ntpdate sntp ${PN}-tickadj ${PN}-utils"
    SYSTEMD_PACKAGES = "${PN} ntpdate sntp"
    $

    $bitbake ntp
    ERROR: ntpdate does not appear in package list, please add it
    ERROR: sntp does not appear in package list, please add it
    $

Signed-off-by: Roy Li <rongqing.li@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Currently we have a hierarchy of pkgdata directories and the code has to put together
a search path and look through each in turn until it finds the data it needs.

This has lead to a number of hardcoded paths and file globing which
is unpredictable and undesirable. Worse, certain tricks that should be
easy like a GL specific package architecture become problematic with the
curretn search paths.

With the modern sstate code, we can do better and construct a single pkgdata
directory for each machine in just the same way as we do for the sysroot. This
is already tried and well tested. With such a single directory, all the code that
iterated through multiple pkgdata directories and simply be removed and give
a significant simplification of the code. Even existing build directories adapt
to the change well since the package contents doesn't change, just the location
they're installed to and the stamp for them.

The only complication is the we need a different shlibs directory for each
multilib. These are only used by package.bbclass and the simple fix is to
add MLPREFIX to the shlib directory name. This means the multilib packages will
repackage and the sstate checksum will change but an existing build directory
will adapt to the changes safely.

It is close to release however I believe the benefits this patch give us
are worth consideration for inclusion and give us more options for dealing
with problems like the GL one. It also sets the ground work well for
shlibs improvements in 1.6.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

fix the following failures:
ERROR: Nothing PROVIDES 'virtual/lib32-i586-pokymllib32-linux-compilerlibs'
ERROR: Nothing RPROVIDES 'lib32-update-alternatives-cworth'

Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

Now that bitbake supports masking events for event handlers, lets use
this so event handlers are only called for events they care about. This
lets us simplify the code indentation a bit at least as well as mildly
improving the event handling performance.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

The PACKAGEFUNCS_append = "do_package_qa_multilib" lacks a "space",
which would cause unexpected errors.

[YOCTO #3190]
[YOCTO #4396]

Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

If we don't do this, multilib packages don't have any code
added to the postinstalls to handle user additions.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>