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. Same use-case broken by this patch reported here: http://lists.linuxtogo.org/pipermail/openembedded-core/2012-May/023154.html Cheers, > > // Robert > > > > >> 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... > > > > Yes, feed updates are not atomic, but this patch breaks moving packages > > between archs like the broken-app example above. In angstrom a machine > > doesn't see feeds with compatible archs at runtime, e.g. beagleboard sees > > beagleboard, armv7a and noarch URIs. This reduces these kind of problems to > > images built with OE. I must note that this setup for feed URIs was done > > out of bandwidth, storage and ram concerns (good old ipkg), not to avoid > > Martins problems :) > > > > regards, > > > > Koen > > _______________________________________________ > > 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 -- Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
