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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2012-09-05 at 15:24 +0200, Koen Kooi wrote:
> Op 5 sep. 2012, om 13:44 heeft Richard Purdie <richard.purdie@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@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 be better than silently doing something non-deterministic.

The bit I hate about this is the fact that sometimes a build would
result in one thing, sometimes another. It should always error out with
an invalid configuration rather than do that.

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

I care more about builds being deterministic than online feeds.
Sorry ;-).

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

Having a different image depending on whether I build MACHINE A or B
first is not what the user expects and is not deterministic in my world
or I suspect in most user's. We can go and ask some if you really think
we need to?

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

How do we detect this? I want deterministic builds so I need the error
to appear regardless of whether I build A or B first (just like I expect
a consistent image).

I also do want to support these situations where we need special
versions. I appreciate its ugly but we have several significant users
with this problem and pretending it doesn't exist doesn't work, much as
I wish we could.

What I really need here is help with coming up with some working
solution. Putting our heads in the sand and arguing whether its even a
problem isn't going to go anywhere :(.

Its really easy to shoot down ideas on the mailing list. Its much harder
to be creative and find ways to take the project to better places whilst
addressing everyone's concerns. I'm starting to find I'm simply
physically and mentally running out of bandwidth for some of these
discussions. I try very hard to hear different opinions, explain
decisions, come up with creative solutions and so on and I think this
process is one of the better features of the project. I am going to need
help in order to be able to continue to do this and scale the project
though.

Cheers,

Richard