[OE-core] [PATCH 1/1] opkg 0.1.8: respect to the arch when choose the alternatives

[Robert Yang]

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.

// 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 at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core