Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 2/6] bitbake.conf: Include the new default-providers.inc and default-versions.inc files
Date: Wed, 11 May 2011 14:34:27 +0100	[thread overview]
Message-ID: <1305120867.30391.353.camel@rex> (raw)
In-Reply-To: <8941115E-22C9-45BD-90EE-4F8A1936AF54@dominion.thruhere.net>

On Wed, 2011-05-11 at 13:43 +0200, Koen Kooi wrote:
> Op 11 mei 2011, om 13:24 heeft Richard Purdie het volgende geschreven:
> 
> > On Wed, 2011-05-11 at 12:08 +0200, Koen Kooi wrote:
> >> Op 11 mei 2011, om 11:09 heeft Richard Purdie het volgende geschreven:
> >> 
> >>> On Tue, 2011-05-10 at 16:20 +0200, Koen Kooi wrote:
> >>>> Op 10 mei 2011, om 16:00 heeft Richard Purdie het volgende geschreven:
> >>>>> +++ b/meta/conf/distro/include/default-providers.inc
> >>>>> @@ -0,0 +1,34 @@
> >>>>> 
> >>>>> +PREFERRED_PROVIDER_gconf ?= "gconf-dbus"
> >>>> 
> >>>> the dbus port has long been merged upstream, so proper gconf would be
> >>>> a better choice. We could ignore it and just use dconf in meta-gnome,
> >>>> though ;)
> >>> 
> >>> I agree we should be using gconf, could someone send me the recipe
> >>> though? ;-).
> >> 
> >> I think we want to keep gconf in meta-gnome and pull the dependants out of oe-core
> > 
> > We have a slight dependency conflict here as we've said we want sato in
> > OECore so we have something we can actually test.
> > 
> > Are we now saying sato also needs to be separated out into its own
> > layer?
> 
> I think that's the best way forward.
> 
> > Or can we define meta-gnome as being the gnome pieces without direct
> > requirements in OECore for a minimal gtk desktop?
> 
> If it's using gconf, it's not a minimal gtk desktop anymore. I see the
> point in having something like sato in oe-core, but I don't think
> that's worth having gconf(-dbus) in oe-core. But this is a different
> discussion, since there are other things that can use gconf (e.g.
> gstreamer) in oe-core, which we would need to take a look at.

It could be argued that gtk with no way to store settings is a little
useless. I'm in favour of having the core graphics testable so I'm not
100% convinced of your argument above. It certainly goes against the
viewpoint that came out of the TSC meetings so we need further
discussion.

In the meantime, replacing gconf-dbus with gconf would seem to move us
closer to where we want to be overall.

> Let's get your distro set merged and then improve on it.

Done :)

Cheers,

Richard




  reply	other threads:[~2011-05-11 13:37 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-10 14:00 [PATCH 0/6] RFC Distro config changes Richard Purdie
2011-05-10 14:00 ` [PATCH 2/6] bitbake.conf: Include the new default-providers.inc and default-versions.inc files Richard Purdie
2011-05-10 14:20   ` Koen Kooi
2011-05-11  9:09     ` Richard Purdie
2011-05-11 10:08       ` Koen Kooi
2011-05-11 11:24         ` Richard Purdie
2011-05-11 11:43           ` Koen Kooi
2011-05-11 13:34             ` Richard Purdie [this message]
2011-05-10 14:00 ` [PATCH 1/6] Drop poky-floating-revisions.inc, poky-bleeding.conf and poky-lsb.conf Richard Purdie
2011-05-10 14:00 ` [PATCH 4/6] machine/qemu: Add qemu-config as an essential machine speicfic dependency and drop specific distro config Richard Purdie
2011-05-10 14:00 ` [PATCH 5/6] conf/distro/include/default-distrovars.inc: Create set of default 'distro' variable values Richard Purdie
2011-05-10 14:26   ` Frans Meulenbroeks
2011-05-10 19:26     ` Richard Purdie
2011-05-11 11:51       ` Frans Meulenbroeks
2011-05-15 20:48   ` Khem Raj
2011-05-19 22:51     ` Richard Purdie
2011-05-10 14:00 ` [PATCH 6/6] preferred-xorg-versions.inc: Drop this, it makes no sense given we only have one version of these recipes Richard Purdie
2011-05-10 14:00 ` [PATCH 3/6] distro: Add defaultsetup.conf, a set of default configuration providing sane overrridable default for commonly used options Richard Purdie
2011-05-10 14:31   ` Koen Kooi
2011-05-11  9:37     ` Richard Purdie
2011-05-15 22:28       ` Khem Raj
2011-05-10 14:05 ` [PATCH 0/6] RFC Distro config changes Frans Meulenbroeks
2011-05-10 14:08   ` Richard Purdie
     [not found]     ` <BANLkTi=uvN8_u6SQhKfs2BwOnSOCQApKSQ@mail.gmail.com>
2011-05-11  3:42       ` Khem Raj
2011-05-10 15:58 ` Koen Kooi
2011-05-11  9:45   ` Richard Purdie
2011-05-11 10:13     ` Koen Kooi
2011-05-11 10:54       ` Richard Purdie
2011-05-11 11:45         ` Koen Kooi
2011-05-15 21:31           ` Khem Raj
2011-05-15 20:22     ` Khem Raj
2011-05-15 21:34       ` Khem Raj
2011-05-11 13:30 ` Richard Purdie
2011-05-15 20:27   ` Otavio Salvador
2011-05-16 12:24     ` 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=1305120867.30391.353.camel@rex \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox