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

[Richard Purdie]

On Fri, 2012-06-01 at 11:04 +0200, Koen Kooi wrote:
> 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.

Its strongly not recommended. You can do it and if things are setup
correctly, we do support machine specific alterations however...

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

I've been assuming this xserver is marked as machine specific. If its
not, that is a bug and we can fix that.

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

As far as I understood Martin's comments, this actually helps avoid some
of the issues he's been experiencing with feeds?

Martin has a problem where machines are ending up with unoptimised
versions of code on them and it would be good to fix opkg behaviour to
do what people expect...

Cheers,

Richard