[OE-core] [PATCH 1/1] qemu: use PACKAGECONFIG to address nss dependencies

[Martin Jansa]

On Fri, Nov 01, 2013 at 07:42:16PM +0800, Hongxu Jia wrote:
> 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.

From this comment it's not clear that people need to comment out
PACKAGECONFIG[foo] lines (not PACKAGECONFIG values) and I believe that setting right
PACKAGECONFIG_pn-qemu-native is more reliable and easier (I don't know
if you can easily remove PACKAGECONFIG varflag from local.conf.

Once I explicitly enable graphics support in my local.conf I would
prefer qemu-native configure to fail if my host distribution is changes
and became incompatible.

>   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
> >
> 

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20131101/3a89991d/attachment-0002.sig>