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

[Tom Rini]

On Thu, Dec 29, 2011 at 5:55 AM, Paul Eggleton
<paul.eggleton at linux.intel.com> wrote:
> 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.

I'm terrible at naming things so I guess backfill is as good as any (I
agree with Phil about introduce).  Option a is clear so long as
there's a good comment, so lets go that way.

-- 
Tom