[OE-core] [PATCH 0/3] Make pulseaudio a DISTRO_FEATURE
Richard Purdie
richard.purdie at linuxfoundation.org
Wed Nov 23 17:09:08 UTC 2011
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
More information about the Openembedded-core
mailing list