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

[Richard Purdie]

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.

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.

> > 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.
> 
> As expected and wanted.

Under certain situations but not this one.

> > 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.
> 
> As pointed out before, your DISTRO needs to fix this and you should
> NOT break opkg in the way you are doing now. 

Maybe.

What you're suggesting is that we have to force every package on a given
architecture to the lowest common denominator which makes no sense.

I understand about the "un-removable" package issue you previously
mentioned. There is a difference between what we build at rootfs time
and any ultimate disto package feeds however and I think we need to at
least consider this proposal.

It would appear at face value to at least make builds deterministic and
do what the users expects them to do. The side effect is making on
target package management more difficult.

Going back to the un-removable package problem, I think that opkg
probably should always prefer arch specific over version. The question
is how do you get back to say arch specific rather than machine specific
at some later date. I'd argue that removing the arch specific package
from the feed would be the trigger for that. Could that work as a
mechanism to get us out of this problematic situation?

Please try and help us figure out a way out of this. I will warn that
above all else builds need to be deterministic and so Robert's patch is
tempting right now as it fixes that.

Cheers,

Richard