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

[Samuel Stirtzel]

2012/1/17 Tom Rini <tom.rini at gmail.com>:
> 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
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Hi,
just a quick question, couldn't we use a separate recipe for phonon,
so if a recipe depends on it we don't have to change distro vars?

To be honest, I haven't thought about the pro and contra about this.
But as I am porting software that "needs" phonon and can't be patched
to remove this need...
IMHO it would be easier to just depend on libphonon.bb instead of
adding a distro var for the one single recipe I'm working on.
Just my 0.02 cents.


By the way: KDE did this too: http://quickgit.kde.org/?p=phonon.git&a=summary


-- 
Regards
Samuel