From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] qemu-native: depend on unfs-server-native
Date: Thu, 03 May 2012 12:51:01 +0100 [thread overview]
Message-ID: <1336045861.30113.83.camel@ted> (raw)
In-Reply-To: <481C530F-A851-4861-B261-9CBE17258D4B@dominion.thruhere.net>
On Thu, 2012-05-03 at 13:39 +0200, Koen Kooi wrote:
> Op 3 mei 2012, om 13:24 heeft Richard Purdie het volgende geschreven:
> > The whole point with the qemu emulated machines is that you build them
> > and they work for new users easily and efficiently. I don't think
> > calling bitbake to build them and force the user into another wait is a
> > good usability model to be promoting.
>
> OE-core should set the right example and teaching people that a global
> IMAGE_DEPENDS is OK is not the right example. Especially when it
> actually causes breakage, see below.
> If people insist that IMAGE_DEPENDS is the one and only way to provide
> the runqemu experience then at least put a big comment in the file
> saying why it's done and why people shouldn't be copy/pasting it into
> their layers.
> And an indiciation where the line is drawn would be nice as well, I
> can imagine that someone wants to add amazon EC2 support to runqemu
> and sends a patch to add the EC2 tools to IMAGE_DEPENDS.
I'm happy to see a comment. The line is quite clear, the documentation
associated with the qemu images, the quick start guide and other manuals
assume we build qemu-native and friends and for usability this is a
clear win. The manuals do not document EC2 and it is not something we
expect a new user to need to do easily. Running an extra "bitbake xxx"
or including an extra configuration file would be perfectly reasonable
for those usage scenarios.
> > I'm also slightly bemused that in previous discussions you've implied
> > build time is less relevant then functionality yet here you're taking
> > the opposite stance :).
>
> I get build *failures* for the qemu machines because I don't have mesa
> and sdl installed on the autobuilder. But you are right, I do think
> build time is less relevant than functionality.
We should also consider setting up PACKAGECONFIG options in the qemu
recipe for these things so you can specify to build qemu-native without
sdl/gl easily. I appreciate that is going to be pretty nasty
implementation wise but I think it would help and in fact if someone
files the bug I'll mark it as a P1 for 1.3 since that does help
usability a lot.
Cheers,
Richard
next prev parent reply other threads:[~2012-05-03 12:00 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-02 14:23 [PATCH] qemu-native: depend on unfs-server-native Jason Wessel
2012-05-02 14:29 ` Koen Kooi
2012-05-02 14:32 ` Martin Jansa
2012-05-02 14:33 ` Jason Wessel
2012-05-02 14:44 ` Koen Kooi
2012-05-02 21:37 ` Jason Wessel
2012-05-03 7:22 ` Koen Kooi
2012-05-02 21:49 ` Phil Blundell
2012-05-02 22:06 ` Mark Hatle
2012-05-02 22:12 ` Jason Wessel
2012-05-03 7:32 ` Khem Raj
2012-05-03 7:43 ` Koen Kooi
2012-05-03 8:47 ` Richard Purdie
2012-05-03 10:39 ` Koen Kooi
2012-05-03 10:57 ` Jason Wessel
2012-05-03 11:24 ` Richard Purdie
2012-05-03 11:39 ` Koen Kooi
2012-05-03 11:51 ` Richard Purdie [this message]
2012-05-04 6:13 ` Koen Kooi
2012-05-04 6:32 ` Martin Jansa
2012-05-04 6:50 ` Koen Kooi
2012-05-04 9:32 ` Richard Purdie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1336045861.30113.83.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.