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

Paul Eggleton paul.eggleton at linux.intel.com
Thu Dec 29 12:55:56 UTC 2011


On Wednesday 23 November 2011 17:09:08 Richard Purdie wrote:
> On Wed, 2011-11-23 at 16:48 +0000, Phil Blundell wrote:
> > b) introduce some sort of concept of "feature epochs", where the DISTRO
> > gets to declare what epoch it is expecting and the compatibility code
> > then backfills DISTRO_FEATURES to take account of things that were
> > enabled by default in past epochs but have since been removed.  This
> > introduces a certain extra maintenance burden but it means that DISTROs
> > will no longer get unpleasant surprises
> 
> 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.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre




More information about the Openembedded-core mailing list