Re: [PATCH 1/1] opkg 0.1.8: respect to the arch when choose the alternatives

[Robert Yang <liezhi.yang@windriver.com>]

On 05/26/2012 04:07 PM, Koen Kooi wrote:
>
> Op 26 mei 2012, om 08:28 heeft Martin Jansa het volgende geschreven:
>
>> On Sat, May 26, 2012 at 10:47:31AM +0800, Robert Yang wrote:
>>>
>>>
>>> On 05/25/2012 07:30 PM, Martin Jansa wrote:
>>>> On Fri, May 25, 2012 at 01:19:55PM +0200, Koen Kooi wrote:
>>>>>
>>>>> Op 25 mei 2012, om 12:02 heeft Robert Yang het volgende geschreven:
>>>>>
>>>>>> There is a bug if we:
>>>>>> 1) bitbake core-image-sato-sdk MACHINE=qemux86
>>>>>> 2) bitbake core-image-sato with MACHINE=crownbay
>>>>>>
>>>>>> Then several pkgs in deploy/ipk/i586 would be installed to crownbay's
>>>>>> image even if there is one in deploy/ipk/core2 and we have set the
>>>>>> core2's priority higher than i586, when the version in deploy/ipk/i586 is
>>>>>> higher. This doesn't work for us, for example, what the crownbay need is
>>>>>> xserver-xorg-1.9.3, but it installs xserver-xorg-1.11.2.
>>>>>>
>>>>>> This is caused by opkg's selecting mechanism, if there are more than one
>>>>>> candidates which have the same pkg name in the candidate list, for
>>>>>> example, the same pkg with different versions, then it will use the last
>>>>>> one which is the highest version in the list, this doesn't work for us,
>>>>>> it should respect to the arch priorities in such a case.
>>>>>
>>>>> This is a serious break with the current opkg behaviour and I don't think it's an improvement. Needing different versions for non machine specific packages indicates a more serious bug elsewhere.
>>>>
>>>> It's not the same use-case as those 2 above, but what I don't like on
>>>
>>> Hi Martin,
>>>
>>> They are the same cases:-), I think that this patch has also fixed your problem,
>>
>> No, at least not completely the same.
>>
>> I would prefer to upgrade foo-1.0-r1_armv4t temporary until
>> foo-1.0-r1_armv7a gets available in feed and that won't happen with your
>> patch AFAIK.
>>
>> with your patch:
>> If you have bar-1.0 which has to be MACHINE_ARCH and in 2.0 bar
>> developers find way to detect and use all machine capabilities in
>> runtime, recipe maintainer will switch to TUNE_ARCH, then
>> foo-1.0_nokia900.ipk won't be ever upgraded to foo-2.0_armv7a.ipk
>> and that's bad.
>
> And what's worse, the cited usecase is for (slightly paraphrasing):
>
> xserver-xorg 1.11.2 i586
> xserver-xorg 1.9.3 i686
>
> Which indicates there is a different, more serious problem at hand. It seems that someone is trying to encode machine specific tweaks to non-machine specific packages. I'm more interested in solving that problem than in changing opkg/rpm behaviour.
>

Yes, fixing the pkg itself is the first way that I had thought:-), but as you
said below, the crownbay board must work with xserver-xorg 1.9.3, and we
can't remove the i586 from crownbay's ARCHs, so the last way I left is fixing
opkg. I think that respect to the arch priority in the multimachine builds
is reasonable as had you suggested before.

// Robert

> There are a number of things that are just not possible to do when supporting multimachine builds and/or multimachine feeds. For example:
>
> machine dogbeachmountain (i686) needs xf86-video-evilpowervr-closedbinary that only works with Xorg 1.9, but machine cherryblossomhighway (i586) can use xf86-video-intel with any xserver-xorg.
> If you want both of these machines to work in multimachine builds and/or feeds, you need to lock down xserver-xorg to 1.9 for i*86. If you don't want to lock it down and imgtec won't give you a better binary drop, too bad, stop doing multimachine.
> I'm not saying the above situation is what Robert is trying to solve, but it's a situation meta-ti is currently facing with the new binary drop for SGX support. When you have dealt with SGX blobs everything starts to look like an SGX problem :)
>
> regards,
>
> Koen
>