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 10:47 AM, 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,
> the foo-1.0_armv7a will be kept now.
Sorry for the typo,    ~~~~~~~~~~~~~~~ Here should be "will be upgraded".

// Robert

>
> // 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
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
>