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
next prev parent 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