Since we now run depmod when building images (as the postinst that does
this is now on kernel-base instead of kernel-image) it is possible to
have module file differences between the two halves of the multilib image,
and the code that checks for such differences detects this and fails.
Whitelist this file to avoid the failure.

Specifically, modules.alias, modules.dep and modules.symbol can differ
along with their .bin counterparts.

Related to fix for [YOCTO #5392].

(From OE-Core master rev: 0a315804bf991664c0948e3024b8e8b9e9085808)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Now that none of the packagegroups depend on virtual/kernel, we have the problem
that MACHINE=qemumips bitbake core-image-minimal doesn't put a kernel
into the deploy directory. This breaks many common usecases and
user expectations.

To avoid this, add a dependency on the kernel deploy to image do_build tasks.
This should avoid any circular dependency issues but equally ensure users
have their expectations met.

[YOCTO #5581]

(From OE-Core master rev: fe26b2379ecdbdb56acde8592bc0c2d95092a207)

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

Conflicts:
	meta/classes/image.bbclass

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

Remove a package from rootfs only if it's already installed. Also,
if a package is uninstalled, remove it from installed_pkgs.txt.

[YOCTO #5169]

Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Setting TEST_IMAGE = "1" alone will now automatically run tests on the
image immediately after the image is built instead of having to add
INHERIT += "testimage" and run bitbake -c testimage <image> manually
(but that will still work). This restores functionality that was
present in the older imagetest-qemu class with IMAGETEST.

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>

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>

In the target sysroot of an SDK we can have target system absolute links
which don't make sense. This adds a script which fixes them up to become relative
paths instead.

[YOCTO #5020]

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

This patch aims to fix the following two cases for the INITRAMFS generation.
  1) Allow an image recipe to specify a paired INITRAMFS recipe such
     as core-image-minimal-initramfs.  This allows building a base
     image which always generates the needed initramfs image in one step
  2) Allow building a single binary which contains a kernel and
     the initramfs.

A key requirement of the initramfs is to be able to add kernel
modules.  The current implementation of the INITRAMFS_IMAGE variable
has a circular dependency when using kernel modules in the initramfs
image.bb file that is caused by kernel.bbclass trying to build the
initramfs before the kernel's do_install rule.

The solution for this problem is to have the kernel's
do_bundle_initramfs_image task depend on the do_rootfs from the
INITRAMFS_IMAGE and not some intermediate point.  The image.bbclass
will also sets up dependencies to make the initramfs creation task run
last.

The code to bundle the kernel and initramfs together has been added.
At a high level, all it is doing is invoking a second compilation of
the kernel but changing the value of CONFIG_INITRAMFS_SOURCE to point
to the generated initramfs from the image recipe.

[YOCTO #4072]

Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Acked-by: Bruce Ashfield <bruce.ashfield@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

These have been deprecated for a long time, convert the remaining
references to the correct modules and prepare for removal of the
compatibility support from bitbake.

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

There is a good chance we might want to support a bitbake operator
"_remove" which works in a similar way to _append and _prepend. As
such, we can't use those keywords in function or variable names.

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

Add the foundation for the PACKAGE_EXCLUDE support.

As part of this work, it was noticed that the PACKAGE_INSTALL and
PACKAGE_INSTALL_ATTEMPTONLY were still using he 'normal' version for
dependencies.  This should no longer be necessary as of the change in the way
the complementary package groups (dev, dbg, ptest and others) are defined.
By making this change the dependency tree is more correct than before, and
gives the ability for manipulating PACKAGE_INSTALL and
PACKAGE_INSTALL_ATTEMPTONLY, while adjusting the dependencies at the same
time.

Warning messages will be generated if the user is trying to exclude a
package that was previously in the PACKAGE_INSTALL or
PACKAGE_INSTALL_ATTEMPTONLY variables.

(See additional commits for package manager specific support.)

Add documentation on PACKAGE_EXCLUDE and related variables.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>