As was discussed in the commit which adds iw:

iw uses cfg80211/nl80211, which is the way of the future. wireless-tools uses
WEXT, which uses ioctl, which is in deep maintenance mode. See
http://wireless.kernel.org/en/developers/Documentation/Wireless-Extensions.
Also https://wireless.wiki.kernel.org/en/users/Documentation/iw indicates "The
old tool iwconfing, which uses Wireless Extensions interface, is deprecated
and it's strongly recommended to switch to iw and nl80211."

wireless-tools is kept as well for now for compatibility reasons, until we
have verified that all the network configuration mechanisms are using iw.

This adds VIRTUAL-RUNTIME_wireless-tools as a distro convenience.

Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

bitbake will currently 'selecting bluez4 to satisfy runtime
libasound-module-bluez due to PREFERRED_PROVIDER_bluez4 = bluez4'
which in the case of bluez5 isn't correct.
This slightly unusual construct avoids this.
Ultimately this is a bitbake issue that needs fixing in
a better way but this means we can merge the bluez5 changes
until bitbake gets fixed.

Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

If BlueZ5 is added to a build as a replacement for BlueZ4,
the provider for bluez-hcidump will be bluez5.

Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

bluez-hcidump was a separate package in bluez4, but was integrated into
bluez5.

Signed-off-by: Peter A. Bigot <pab@pabigot.com>

getopt can be provided by either util-linux or busybox. Allow the
distro to control which implementation is used, and default it to
util-linux.

Signed-off-by: Richard Tollerton <rich.tollerton@ni.com>
Acked-by: Ken Sharp <ken.sharp@ni.com>
Acked-by: Ben Shelton <ben.shelton@ni.com
Acked-by: Brad Mouring <brad.mouring@ni.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

The base_contains is kept as a compatibility method and we ought to
not use it in OE-Core so we can remove it from base metadata in
future.

Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

This allows dependencies to be added to the opkg recipe without causing circular
dependency loops. As opkg-utils has minimal dependencies it is the best recipe
to provide update-alternatives.

This partially solves Yocto Project issue 4836. More work is still needed for a
complete solution.

Signed-off-by: Paul Barker <paul@paulbarker.me.uk>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

* ltp installs 2 different runtests_noltp.sh files from different
  directories into /opt/ltp/testcases/bin/runtests_noltp.sh
  last one installed wins and causes unexpected changes in
  buildhistory's files-in-image.txt report, rename them to have
  unique name as other ltp scripts have.

* also define PREFERRED_PROVIDER to resolve note shown when
  building with meta-oe layer:
  NOTE: multiple providers are available for ltp (ltp, ltp-ddt)
  NOTE: consider defining a PREFERRED_PROVIDER entry to match ltp

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

As there are two alternative mesa recipes (mesa and mesa-gl), there needs to be
a virtual provider that recipes that explicitly need Mesa (such as xserver-xorg)
can depend on.

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

There is a need for a default provider for bluez
now that bluez5 recipe is also present.

After the introduction of bluez5 recipe,
the following warnings are displayed:

"NOTE: multiple providers are available for runtime libasound-module-bluez (bluez4, bluez5)
 NOTE: consider defining a PREFERRED_PROVIDER entry to match libasound-module-bluez"

Upon debug, bitbake shows:
DEBUG: checking PREFERRED_PROVIDER_bluez4 (value None) against ['bluez4', 'bluez5']
DEBUG: checking PREFERRED_PROVIDER_bluez4-4.101 (value None) against ['bluez4', 'bluez5']
DEBUG: checking PREFERRED_PROVIDER_bluez4-4.101-r5 (value None) against ['bluez4', 'bluez5']
DEBUG: checking PREFERRED_PROVIDER_bluez5 (value None) against ['bluez4', 'bluez5']
DEBUG: checking PREFERRED_PROVIDER_bluez5-5.7 (value None) against ['bluez4', 'bluez5']
DEBUG: checking PREFERRED_PROVIDER_bluez5-5.7-r0 (value None) against ['bluez4', 'bluez5']

Bitbake is faced with the question "what should provide libasound-module-bluez?"
which is a runtime name. It needs to try and find a PREFERRED_PROVIDER entry
which matches this but those use *build time* naming. So it converts "libasound-module-bluez"
into the canonical ${PN} of bluez4 and bluez5 and then tries to look those up.
What it actually should do is go one step further of mapping bluez4/bluez5
into the virtual/bluez but that does not happen.

Bug opened on this issue: YB5044
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5044

[YOCTO #5030]

Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>