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