Re: [PATCH 0/3] Make pulseaudio a DISTRO_FEATURE

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2011-11-23 at 16:48 +0000, Phil Blundell wrote:
> On Wed, 2011-11-23 at 16:33 +0000, Paul Eggleton wrote:
> > On Wednesday 23 November 2011 16:59:56 Koen Kooi wrote:
> > > We also agreed that the current behaviour should be retained, so needing to
> > > add pulse to distro features would go against that. Having said that, I
> > > personally would dislike having negative ('nopulseaudio') entries to
> > > address that. Feedback needed :)
> > 
> > I don't see how we can achieve this without making a huge mess. I'm happy to 
> > be proven wrong, but I would really like us to figure this stuff out soon so we 
> > can get the actual problem here fixed.
> 
> Agreed.  This problem (or variants of it) comes up fairly frequently: we
> had a similar amount of grief when ipv4 and ipv6 became DISTRO_FEATURES
> and everybody who wasn't paying attention found that they suddenly had
> no networking.  But I think it is basically insoluble in the general
> case without any extra stateful mechanics: we need to either:
> 
> a) decide that what we have today, or at some other arbitrary point, is
> the "base configuration" and any departure from that (including
> removals) will now be a DISTRO_FEATURE.  This means accepting things
> like "nopulseaudio" which are, admittedly, ugly; or
> 
> 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; or
> 
> c) just live with the status quo and accept that things will break when
> features are turned off.
> 
> My personal preference would be for (b) but I could live with (a) just
> as well.

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.

Cheers,

Richard