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

[Koen Kooi]

Op 1 jun. 2012, om 10:17 heeft Richard Purdie het volgende geschreven:

> On Thu, 2012-05-31 at 17:01 +0200, Koen Kooi wrote:
>> Op 31 mei 2012, om 16:13 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.
>> 
>> And this is working exactly as intended. Don't break opkg because your
>> hardware driver situation sucks.
>> 
>> So: NAK on this patch.
> 
> I think we do have a problem here. For example, the system is ignoring a
> PREFERRED_VERSION directive here

A PREFERRED_VERSION set in a machine.conf, which is the wrong place. Let's change the above build sequence to this:

1) MACHINE=qemux86 bitbake xserver-xorg
2) MACHINE=othercore2machine bitbake xserver-xorg
3) MACHINE=crownbay bitbake xserver-xorg

Oh look, I get 1.11.2 on crownbay regardless of this patch.

> by building one thing and then
> installing another. We're also inconsistent between the dpkg/rpm and
> opkg backends. There is therefore definitely some kind of user
> experience issue at stake here since this behaviour is not obvious,
> expected or particularly correct.
> 
> The fact the example is hardware related is not particularly relevant,
> its the bigger picture I worry about

I also worry about the bigger picture, especially about what Martin said about this breaking feeds.