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

[Martin Jansa]

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
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,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20120525/403b5012/attachment-0002.sig>