Re: [PATCH 1/1] qemu: use PACKAGECONFIG to address nss dependencies

[Hongxu Jia <hongxu.jia@windriver.com>]

On 11/01/2013 06:52 PM, Richard Purdie wrote:
> On Fri, 2013-11-01 at 10:39 +0100, Martin Jansa wrote:
>> On Fri, Nov 01, 2013 at 08:50:56AM +0000, Richard Purdie wrote:
>>> On Thu, 2013-10-31 at 19:50 +0800, Hongxu Jia wrote:
>>>> On 10/31/2013 06:41 PM, Martin Jansa wrote:
>>>>> On Thu, Oct 31, 2013 at 06:23:01PM +0800, Hongxu Jia wrote:
>>>>>> Use PACKAGECONFIG to explicitly address nss dependencies rather than
>>>>>> tested by configure.
>>>>>>
>>>>>> It avoided potential errors while multiple builds shared a common
>>>>>> state_cache.
>>>>> There are more floating dependencies in qemu.inc, see
>>>>> http://patchwork.openembedded.org/patch/56935/
>>>>>
>>>>> and even this list isn't complete, there is also:
>>>>> WARN: packages/armv5te-oe-linux-gnueabi/qemu/qemu/latest lost dependency on  cairo gdk-pixbuf gnutls gtk+ libvte
>>>>>
>>>>> Can you please improve it to fix them all?
>>>>>
>>>> OK, I will try to fix them as possible as I can.
>>>>
>>>> Drop this patch, wait for V2.
>>> Part of the problem here is that qemu-native has some "floating"
>>> dependencies by design. If the native system has graphics support, qemu
>>> will have too. If it doesn't it won't have. This works out to be quite
>>> useful for people. Some people have headless build machines they don't
>>> want to install X on, equally some have build machines which do have X
>>> and they do want graphical qemu.
>>>
>>> How do we support both?
>> Aren't reproducible builds more important than automagically enabled
>> graphics support, what if such automagically enabled qemu-native gets
>> reused from sstate on headless server without graphics support?
> I agree there is a problem here. Equally, there is an important use case
> which people do use and care about which this patch removes.
>
>> We can extend documentation to say that in order to enable graphics
>> support for qemu-native you need to set
>> PACKAGECONFIG_pn-qemu-native += "foo bar"
>> in local.conf (or to remove some to disable it, but enabling explicitly
>> is imho better because we don't have graphics native support in
>> ASSUME_PROVIDED).
> I think we'll have to do something like this, yes. I'd like to see the
> patches adding this documentation to local.conf before we change things
> though.

OK, how about add the above documentation as comments in the patch.
...
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -79,6 +79,10 @@ do_install_append() {
  }
  # END of qemu-mips workaround

+# Disable the following flags by default. Such as graphics is
+# disabled for qemu-native, if you need to enable them, set
+# PACKAGECONFIG_pn-qemu-native += "foo bar" in local.conf
+# or just comment out them to let configure do the test.
  PACKAGECONFIG ??= ""
  PACKAGECONFIG[virtfs] = "--enable-virtfs 
--enable-attr,--disable-virtfs,libcap attr,"
  PACKAGECONFIG[aio] = "--enable-linux-aio,--disable-linux-aio,libaio,"
...

or add them to meta-yocto/conf/local.conf.sample.extended or some place 
else?

And I could not exactly figure out which flags affected the graphics.

//Hongxu


> Cheers,
>
> Richard
>