[OE-core] [PATCH] qemu-native: depend on unfs-server-native

[Koen Kooi]

Op 3 mei 2012, om 13:24 heeft Richard Purdie het volgende geschreven:

> On Thu, 2012-05-03 at 12:39 +0200, Koen Kooi wrote:
>> Op 3 mei 2012, om 10:47 heeft Richard Purdie het volgende geschreven:
>> 
>>> On Thu, 2012-05-03 at 09:43 +0200, Koen Kooi wrote:
>>>> Op 3 mei 2012, om 09:32 heeft Khem Raj het volgende geschreven:
>>>> 
>>>>> On Wed, May 2, 2012 at 7:23 AM, Jason Wessel <jason.wessel at windriver.com> wrote:
>>>>>> The user mode NFS server does not get built by default when you are
>>>>>> using a purely command line driven development environment without SDK
>>>>>> tools.  In order to accommodate simple test configurations and have
>>>>>> all the tools built for the minimal validation with qemu-native,
>>>>>> simply add the dependency to unfs-server-native.
>>>>>> 
>>>>>> Signed-off-by: Jason Wessel <jason.wessel at windriver.com>
>>>>>> ---
>>>>>> meta/conf/machine/include/qemu.inc |    2 +-
>>>>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>>>> 
>>>>>> diff --git a/meta/conf/machine/include/qemu.inc b/meta/conf/machine/include/qemu.inc
>>>>>> index 421a149..742b629 100644
>>>>>> --- a/meta/conf/machine/include/qemu.inc
>>>>>> +++ b/meta/conf/machine/include/qemu.inc
>>>>>> @@ -14,4 +14,4 @@ RDEPENDS_kernel-base = ""
>>>>>> # Use a common kernel recipe for all QEMU machines
>>>>>> PREFERRED_PROVIDER_virtual/kernel ?= "linux-yocto"
>>>>>> 
>>>>>> -EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native"
>>>>>> +EXTRA_IMAGEDEPENDS += "qemu-native qemu-helper-native unfs-server-native"
>>>>>> --
>>>>> 
>>>>> how about replacing  EXTRA_IMAGEDEPENDS with
>>>>> MACHINE_ESSENTIAL_EXTRA_RDEPENDS here ?
>>>> 
>>>> RDEPENDS end up in the image, IMAGEDEPENDS are needed to build the
>>>> image. Do I need qemu-native, helper-native and unfs to build the
>>>> image? No I don't. Would I need it if I decide to run the runqemu
>>>> scripts, yes. Do these extra dependencies cause pain? Yes, since it
>>>> requires installing tons of extra things on a headless buildserver
>>>> (mesa, sdl) to just build an image.
>>>> 
>>>> If I wanted to be an ass I would suggest moving qemu-native,
>>>> qemu-helper-native and unfs-server-native to the HOB, but I won't do
>>>> that.
>>>> 
>>>> So I'll stick with my original suggestion: move those dependencies to
>>>> the images you want to run on nfs for qemu, don't pollute the global
>>>> EXTRA_IMAGEDEPENDS with it.
>>> 
>>> If I wanted to be an ass here I'd just add them to the image class
>>> conditional on qemu. This would be a little pointless and needlessly
>>> complicate things though.
>>> 
>>> The point of these is to trigger them to build whenever a qemu image is
>>> built. This makes a lot of sense in some use cases, it also does not
>>> make sense in some other cases and it is not possible for the system to
>>> mind read and tell the difference.
>> 
>> What about having the runqemu* scripts call bitbake to build the
>> -native helpers when they are missing? 
> 
> 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 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.