* There would be race issue if we put the lock to the WORKDIR, for
  example:
  bitbake core-image-sato core-image-sato-sdk

  If the lock is in their own WORKDIR, the apt-rootfs.conf and
  Packages.gz maybe be written by two tasks at the same time, which
  would cause unexpected errors.

* Create ${target_rootfs}/etc since the "tar -C" needs it.

Note:
  * The rpm has put the lock to DEPLOY_DIR_RPM
  * The ipk doesn't need it since it has locks for each deploy directory
    and put the opkg.conf in his own WORKDIR, which doesn't like deb put
    the apt-rootfs.conf in ${STAGING_ETCDIR_NATIVE}/apt/.

[YOCTO #2495]

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

Use a similar mechanism that was previously used to install locales at
rootfs generation time to install other "complementary" packages (e.g.
*-dev packages) - i.e. install all of the explicitly requested packages
and their dependencies, then get a list of the packages that were
installed, and use that list to install the complementary packages. This
has been implemented by using a list of globs which should make it
easier to extend in future.

The previous locale package installation code assumed that the locale
packages did not have any dependencies that were not already installed;
now that we are installing non-locale packages this is no longer
correct. In practice only the rpm backend actually made use of this
assumption, so it needed to be changed to call into the existing package
backend code to do the complementary package installation rather than
calling rpm directly.

This fixes the doc-pkgs IMAGE_FEATURES feature to work correctly, and
also ensures that all dev/dbg packages get installed for
dev-pkgs/dbg-pkgs respectively even if the dependency chains between
those packages was not ensuring that already.

The code has also been adapted to work correctly with the new
SDK-from-image functionality. To that end, an SDKIMAGE_FEATURES variable
has been added to allow specifying what extra image features should go
into the SDK (extra, because by virtue of installing all of the packages
in the image into the target part of the SDK, we already include all of
IMAGE_FEATURES) with a default value of "dev-pkgs dbg-pkgs".

Fixes [YOCTO #2614].

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

When building an image recipe, you can now build a companion SDK by
calling the populate_sdk task:
  bitbake -c populate_sdk core-image-minimal

Note: there are still issues w/ the SDK not working completely with
multilibs.

A lock is required between rootfs and populate_sdk activities to prevent
configuration file clashes and similar package management problems in ipk
and deb based systems.  (RPM already had a lock for a different reason.)

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>

We want to be able to supply attempt only packages in the SDK in order to
support more advanced SDK images that more closely match specific image
recipes.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>

Using "1" with getVar is bad coding style and "True" is preferred.
This patch is a sed over the meta directory of the form:

sed \
 -e 's:\(\.getVar([^,()]*, \)1 *):\1True):g' \
 -e 's:\(\.getVarFlag([^,()]*, [^,()]*, \)1 *):\1True):g' \
 -i `grep -ril getVar *`

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

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

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

This is the result of running the following over the metadata:

sed \
-e 's:bb.data.\(setVar([^,()]*,[^,()]*\), *\([^ )]*\) *):\2.\1):g' \
-e 's:bb.data.\(setVarFlag([^,()]*,[^,()]*,[^,()]*\), *\([^) ]*\) *):\2.\1):g' \
-e 's:bb.data.\(getVar([^,()]*\), *\([^(), ]*\) *,\([^)]*\)):\2.\1,\3):g' \
-e 's:bb.data.\(getVarFlag([^,()]*,[^,()]*\), *\([^(), ]*\) *,\([^)]*\)):\2.\1,\3):g' \
-e 's:bb.data.\(getVarFlag([^,()]*,[^,()]*\), *\([^() ]*\) *):\2.\1):g' \
-e 's:bb.data.\(getVar([^,()]*\), *\([^) ]*\) *):\2.\1):g' \
-i `grep -ril bb.data *`

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

[YOCTO #1086]

The pach was backported from OE:
http://git.openembedded.net/cgit.cgi/openembedded/commit/?id=41e0fbf792037f249d1b8d283b3de81718887c9f

Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>

[YOCTO #1070]

Currently with deb packaging, we have 2 issues when running
"bitbake meta-toolchain-gmae".

1) when MACHINE="qemux86", SDKMACHINE="i686", INSTALL_BASEARCH_DEB is "i686",
too. This causes the following ERROR:
| E: Couldn't find package task-sdk-host-nativesdk
NOTE: package meta-toolchain-gmae-1.0-r6: task do_populate_sdk: Failed

This is becasue: due to the DPKG_ARCH mapping, we create such a deb package
tmp/deploy/deb/i686-nativesdk/task-sdk-host-nativesdk_1.0-r10_i386.deb; dpkg
can't recoginze the package. We need to map INSTALL_BASEARCH_DEB in the same
way.

2) when MACHINE="qemux86", SDKMACHINE="x86_64", INSTALL_BASEARCH_DEB is
"x86_64", too.
We get such an ERROR:
| E: Couldn't find package task-cross-canadian-i586
NOTE: package meta-toolchain-gmae-1.0-r6: task do_populate_sdk: Failed

This is because: dpkg can't recognize the generated package
tmp/deploy/deb/x86_64-nativesdk/task-cross-canadian-i586_1.0-r0_i386.deb
Here the "i386" suffix is incorrect and should be "x86_64" -- the i386
comes from the line
DPKG_ARCH_i586 ?= "i386" in package_deb.bbclass.
However, for canadian package, actually here the overriding of DPKG (from
"x86-64" to "i386") should not happen -- it accidently happens just because
TARGET_ARCH exists in OVERRIDES. We can move the overriding logic to the
anonymous python function to work this around.

Signed-off-by: Lianhao Lu <lianhao.lu@intel.com>
Signed-off-by: Dexuan Cui <dexuan.cui@intel.com>