[OE-core] [PATCH 0/3] Make pulseaudio a DISTRO_FEATURE

[Phil Blundell]

On Mon, 2012-01-16 at 17:58 +0000, Paul Eggleton wrote:
> On Thursday 29 December 2011 12:55:56 Paul Eggleton wrote:
> > On Wednesday 23 November 2011 17:09:08 Richard Purdie wrote:
> > > I'm wondering if we can do something in the core like:
> > > 
> > > DISTRO_FEATURES_BACKFILLOPTS = "pulseaudio"
> > > 
> > > and have the distro set:
> > > 
> > > DISTRO_FEATURES_BACKFILLCONSIDERED = ""
> > > 
> > > and then add some code which looks for anything in
> > > DISTRO_FEATURES_BACKFILLOPTS but not in
> > > DISTRO_FEATURES_BACKFILLCONSIDERED and adds it to DISTRO_FEATURES.
> > > 
> > > Distros can then opt out of a given feature by adding it to
> > > DISTRO_FEATURES_BACKFILLCONSIDERED.
> > > 
> > > This would let us maintain compatibility but also move forward and
> > > create new settings with names that make sense.
> > 
> > I'd like to try to move forward with this fix (although I prefer an
> > alternative term to "backfill", perhaps "introduce" instead?) If this is
> > what we want to do, should it be implemented by:
> > 
> > (a) modifying DISTRO_FEATURES directly (as I think Richard is suggesting),
> > or
> > 
> > (b) a simple python call that the distro needs to add to their own
> > DISTRO_FEATURES (i.e. "${@distro_features_introduce(d)}" ?
> > 
> > Option (a) is a little tidier but (b) makes it obvious where any introduced
> > items in DISTRO_FEATURES are coming from.
> 
> This was brought up at the last TSC meeting, but we agreed to leave the 
> discussion on the mailing list for the moment.
> 
> So, any thoughts?

Personally I prefer option (a) and Richard's terminology.  I think the
"introduce" naming is a bit too vague and generic and doesn't really
capture what's going on here.

p.