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