This converts the option to maintain the existing behaviour unless the option is
specified. We do specify the option during the builds themselves to ensure what
the users expects is built.

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

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

All variants of opkg are currently configured --disable-curl so there
seems no point in depending on it.

Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Even when installing onto a live target system, calling sync() during
package installation is of somewhat questionable benefit.  But calling
it on the build host during rootfs construction is certainly useless and
can cause I/O to stall for several seconds on even a moderately sized
host which is clearly not desirable.

(From a patch originally by Mike Crowe.)

Signed-off-by: Phil Blundell <philb@gnu.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

* http://code.google.com/p/opkg/issues/detail?id=94

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

This is for fixing the problem:
1) bitbake core-image-sato-sdk with MACHINE=qemux86
2) bitbake core-image-sato with with MACHINE=crownbay

The qemux86's PACKAGE_ARCH is i586, the crownbay's is core2, but several
i586 packages will be installed into crownbay's rootfs though there are
core2 packages. For example, there are:

xserver-xorg*_1.11.2-r7_i586.ipk
xserver-xorg*_1.9.3-r1_core2.ipk

The crownbay.conf says:
PREFERRED_VERSION_xserver-xorg ?= "1.9.3"

What the crownbay's image needs is xserver-xorg*_1.9.3-r1_core2.ipk, but
the xserver-xorg*_1.11.2-r7_i586.ipk will be installed, this is
incorrect.

This is caused by opkg's selecting mechanism: when more than one
candidate is found, it will use the higher version one and ignore the
arch priority.

we have several conf files which set the PREFERRED_VERSION_pkg = "..." ,
but there is no such a mechanism which can let us tell the opkg to
install the preferred version. When the preferred version is higher,
this is OK, but if the preferred version is lower, there would be
problems:

1) Most of the packages are core2 in the image, but several of them are
   i586, though we have built the core2 ones, this seems strange.

2) What's worse is that the image may not work since the preferred
   version pkg is not installed.

We have set the arch priority clearly in the opkg.conf, I think that
respect to the arch priority is reasonable during the image generation.

Add the "--select-higher-version" option to let the user have another
choice, the default is no.

[YOCTO #2575]

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

* use SRCREV from opkg_svn.bb, because with 596 patches we have won't apply

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

* it was triggered by c02364f36e228835ea5d7fd4e1d347fd451f8544 when new package had 2 entries in Provides and old version just 1

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>

Remove opkg_0.1.8.bb and the related files since it doesn't work:

- It doesn't support the "--force_postinstall" option which is used by
  package_ipk.bbclass.

- It still doesn't work after remove the "--force_postinstall" option,
  it can't install the packages in complementary_pkgs.txt.

[YOCTO #3136]

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