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