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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

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.

Cheers,

Richard