Op 4 jun. 2012, om 12:39 heeft Martin Jansa het volgende geschreven: > On Mon, Jun 04, 2012 at 05:31:26PM +0800, Robert Yang wrote: >> >> >> On 06/01/2012 06:35 PM, Koen Kooi wrote: >>> >>> Op 1 jun. 2012, om 12:02 heeft Richard Purdie het volgende geschreven: >>> >>>> 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. >>> >>> the X server not machine specific and that is NOT a bug. The recipe for the >>> DDX only works with a specific X version. The real problem here is that >>> xf86-video-something (again, not machine specific, think pci cards) has a >>> strict requirement on the x server version. This is now purely a DISTRO >>> problem. A few possible solutions are: >>> >>> 1) Lock X to 1.9.3 for all compatible x86 archs in your DISTRO >>> 2) Lock X to 1.11.2 for all compatible x86 archs in your DISTRO, live with >>> the crownbay breakage >>> 3) Only use a package manager with no notion of compatible archs (dpkg) or >>> with strong version pinning (rpm) >>> 4) Be really careful with the build sequence and structure your feed >>> configs to not have compatible archs in their feed URIs >>> 5) remove 'x11' from DISTRO_FEATURES >>> >>> This is a point where you cannot make everybody happy. But as you say >>> below, let's decouple the above problem from the arch vs version discussion. >>> >>>>>> 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? >>> >>> No, it allows you to add a package-of-death. Example: >>> >>> broken-app_1.0_machine.ipk is in the feeds, being machine specific >>> broken-apps author fixes the machine specific bits properly >>> broken-app_2.0_i586.ipk hits the feeds and is not picked up. >> >> I think that the broken-app_2.0_i586.ipk came unexpectedly, >> there was a broken-app_1.0_machine.ipk (maybe also broken-app_1.0_i586.ipk, >> but it didn't matter), if it has been fixed to version 2.0, then there should >> be also a broken-app_2.0_machine.ipk (and it would be picked up). > > If broken-app developers are now detecting machine capabilities (or > whatever) since 2.0 in runtime, then we don't need to build broken-app > for every single machine we support, so changing PACKAGE_ARCH from > MACHINE_ARCH to TUNE_PKGARCH is right thing to do to save compile time > and feed disk space.
Exactly > Same use-case broken by this patch reported here: > http://lists.linuxtogo.org/pipermail/openembedded-core/2012-May/023154.html I borrowed heavily from your post since both Richard and Robert don't seem to see the damage this will do to feeds when a package/recipe changes archs. regards, Koen _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
