[OE-core] [RFC PATCH 2/2] package_ipk.bbclass: use "--force-arch" when install package

[Koen Kooi]

Op 5 sep. 2012, om 13:44 heeft Richard Purdie <richard.purdie at linuxfoundation.org> het volgende geschreven:

> On Wed, 2012-09-05 at 12:05 +0200, Koen Kooi wrote:
>> Op 5 sep. 2012, om 11:31 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-r4_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-r4_i586.ipk will be installed, this is
>>> incorrect.
>> 
>> It is the correct behaviour, though.
> 
> No, it isn't. You told bitbake to build some specific versions, it did
> that, then put something else in the rootfs. Without mentioning any of
> this to the user.

You forget that, you, as the user, instructed bitbake to build the other version when switching machine. Should bitbake refuse to build the packages in this scenario? That would make more sense than trying to clean up the mess in the package_ipk bbclass. If you have online feeds the problem will reappear anyway.

> So the current behaviour is totally broken and it needs to do one of:
> 
> a) Put the things the user asked for in the rootfs
> b) Tell the user its not going to
> c) Error out and ask the user to fix the problem
> 
> Builds are meant to be deterministic and this clearly isn't as what you
> get out depends on the order of what you build.

How do we know what the user expects? The user already did something that isn't right by building compatible arch packages with different versions. And this is deterministic, the user instructed bitbake to build a more recent, but compatible version, which will end up in the rootfs. If would be non-deterministic if opkg would decide at random what to install.

So, fix this problem at the root and make bitbake error out if your build breaks PREFERRED_VERSION.