[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