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

[Koen Kooi]

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.

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

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.

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?