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

[Richard Purdie]

On Thu, 2012-09-06 at 13:05 +0200, Koen Kooi wrote:
> Op 5 sep. 2012, om 23:19 heeft Richard Purdie <richard.purdie at linuxfoundation.org> het volgende geschreven:
> 
> > On Wed, 2012-09-05 at 15:24 +0200, Koen Kooi wrote:
> >> 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 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.
> 
> Thanks for going on the record for that.

We're a build system and package feed creation has always been argued to
be a second step based on the output of the build system, often by you
iirc.
> > 
> >> 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 :(.
> 
> Where have I argued that it's not a problem? I've said time and time
> again that PREFERRED_VERSION problems are for the DISTRO to solve. You
> are arguing that we should band-aid it somewhere in a class where it
> would break package feeds. So my counter proposal for broken DISTROs
> was to have bitbake completely prevent the user from building such a
> conflicting version.

I'd argue its up to the DISTRO to solve at package feed generation time
and that is the point it should error. I cannot see any way bitbake can
reasonably figure out this problem and accurately error as it simply
doesn't have the info. At package feed generation time, you do have that
info.

On the other hand, the build system *can* generate images consistently.

> The low-tech solution would be to document that you can't build this
> combination of machines in the same TMPDIR. Wiping TMDIR between
> machines changes should be quite cheap with sstate-cache nowadays, no?

By your own reasoning, this is unacceptable since the generated images
would differ from what online package management would result in with
image upgrades.

Documenting the builds aren't deterministic is a fail, we can do better.

Cheers,

Richard