[OE-core] [PATCH 1/1] opkg svn: respect to the arch priority

Koen Kooi koen at dominion.thruhere.net
Fri Sep 21 14:22:53 UTC 2012


Op 18 sep. 2012, om 17:25 heeft Robert Yang <liezhi.yang at windriver.com> het volgende geschreven:

> 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.

So what happens when I force crownbay to use i586 as package arch? Are you still going to argue that 1.9.3 should be installed?

> 
> 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.

The default should be yes, since that is the default behaviour right now. You can set it to 'no' in rootfs_ipk.bbclass, though.



More information about the Openembedded-core mailing list