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 02:28 PM, Martin Jansa wrote:
> 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

I think it can upgrade foo-1.0-r1_armv4t temporarily, if ipk/armv7a is removed
from the repository, then it would not appear in the opkg.conf, and the armv7a
should be the lowest priority and an unknown arch, and foo-1.0-r1_armv4t will
win, and it would be installed.

I simulated your environment:(with core2 and i586, core2 has a higher version)

1) The foo-1.0_r1.core2 installed

2) Remove the core2 related lines from core-image-sato-1.0-r0/opkg.conf and 
core-image-sato-1.0-r0/rootfs/etc/opkg/arch.conf

3) opkg update && opkg upgrade (foo-1.0_r1.i586 upgraded)

4) Add the core2 related lines back to core-image-sato-1.0-r0/opkg.conf and 
core-image-sato-1.0-r0/rootfs/etc/opkg/arch.conf

5) opkg update && opkg upgrade (foo-1.0_r1.core2 upgraded)

// Robert

> 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.
>
> Cheers,
>
>> the foo-1.0_armv7a will be kept now.
>>
>> // Robert
>>
>>> current opkg behaviour is that it doesn't "reinstall" the package with
>>> the same version when it gets available in arch with higher priority.
>>>
>>> e.g. I have armv7a device which has feed urls for armv4t and armv7a
>>> (armv7a of course with higher priority).
>>>
>>> foo-1.0 in both feeds armv4t armv7a
>>>
>>> opkg update&&   opkg install foo ->   foo-1.0_armv7a
>>>
>>> distro builder publish foo-1.0-r1 sofar only in armv4t feed
>>>
>>> opkg update&&   opkg upgrade ->   foo-1.0_armv7a is upgraded to foo-1.0-r1_armv4t)
>>>
>>> distro builder publish foo-1.0-r1 also to armv7a feed
>>>
>>> opkg update&&   opkg upgrade ->   nothing, but "upgrading" to foo-1.0-r1_armv7a) would be better
>>>
>>>
>>> On my distro builder I'm trying to prevent this scenario by rsyncing
>>> feeds only after build for *all* supported machines is completed, but
>>> that's still not really atomic operation. (And later I've also started
>>> to filter feeds which gets available on target image).
>>>
>>> Cheers,
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>