Make pulseaudio a DISTRO_FEATURE

The initial driver behind this series was a failure on our autobuilder, which resulted from qt4-x11-free detecting pulseaudio at configure time but then since it wasn't listed in DEPENDS, when it came to compile time pulseaudio happened to be unavailable and the build failed. Since pulseaudio becomes a hard runtime dependency of phonon when it is enabled,

and it is an optional build-time dependency more than one recipe it makes sense to make it a DISTRO_FEATURE.

Note that should this patchset be accepted, distro maintainers will need to add pulseaudio to their DISTRO_FEATURES to retain the current behaviour.

The phonon backends (e.g. gstreamer) are nicely modularized is the pulseaudio case different?

We discussed this in yesterdays TSC meeting and I hope I paraphrase the consenses correctly: we want to use PACKAGECONFIG to do the heavy lifting (DEPENDS, EXTRA_OECONF) and have DISTRO_FEATURES do the triggering. RP pointed out that having DISTRO_FEATURES trigger PACKAGECONFIG currently leads to a convoluted syntax which we need to address.

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 :)

Quoted 4 lines · 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.

Quoted 9 lines · Paul Eggleton

Quoted 4 lines · 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.

In that case, should we
not be providing the appropriate mechanism so that can exclude the features

I think I'm right in assuming that when we introduce a DISTRO_FEATURES feature we are almost always doing it to allow disabling some existing functionality, rather than enabling something new.

In that case, should we not be providing the appropriate mechanism so that can exclude the features they don't want rather than including the ones that they do?

This will solve the issue, but the more I think about it the more I don't like it - from the perspective of a new user it just puts a fairly arbitrary line between old features and new ones. If you want control over the full range of options you'll need to look at two places.

...

"old" features but it isn't going to be a hard, fixed division and I would expect that most DISTROs will do a fairly good job of keeping up to date with the newly introduced flags.

Quoted 6 lines · Phil Blundell

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.

Quoted 23 lines · On Wednesday 23 November 2011 17:09:08 Richard Purdie wrote:

Quoted 9 lines · Phil Blundell

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.

Quoted 5 lines

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.

Quoted 29 lines · On Thursday 29 December 2011 12:55:56 Paul Eggleton wrote:

Quoted 12 lines · On Wednesday 23 November 2011 17:09:08 Richard Purdie wrote:

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.

Quoted 5 lines

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)}" ?

Quoted 2 lines

Option (a) is a little tidier but (b) makes it obvious where any introduced items in DISTRO_FEATURES are coming from.

This was brought up at the last TSC meeting, but we agreed to leave the discussion on the mailing list for the moment.

So, any thoughts?

Quoted 20 lines · On Wednesday 23 November 2011 17:09:08 Richard Purdie wrote:

Quoted 6 lines · Phil Blundell

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.

Quoted 5 lines

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.

Quoted 40 lines · On Thursday 29 December 2011 12:55:56 Paul Eggleton wrote:

Quoted 23 lines · On Wednesday 23 November 2011 17:09:08 Richard Purdie wrote:

Quoted 9 lines · Phil Blundell

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.

Quoted 5 lines

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)}" ?

Quoted 2 lines

Option (a) is a little tidier but (b) makes it obvious where any introduced items in DISTRO_FEATURES are coming from.

This was brought up at the last TSC meeting, but we agreed to leave the discussion on the mailing list for the moment.

So, any thoughts?

Quoted 31 lines · Paul Eggleton

Quoted 20 lines · On Wednesday 23 November 2011 17:09:08 Richard Purdie wrote:

Quoted 6 lines · Phil Blundell

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.

Quoted 5 lines

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:

Quoted 7 lines

(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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

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?

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.

Quoted 2 lines

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?

Well, this thread is now about something more fundamental (how to introduce new DISTRO_FEATURES), but we do still need to solve the problem that prompted the wider discussion. It's still possible that someone would want to build phonon without pulseaudio, even if it was split out into a separate recipe, so I'm not sure that addresses the problem.

Quoted 4 lines

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.

Pulseaudio has become an optional dependency for a lot of things. I think it makes sense to make a decision on whether or not to include this on a distro level since if you have it enabled in one place you almost certainly want it enabled everywhere else (and disabled everywhere if it is disabled).

Now, at the start of this saga there was a question as to whether this should be a DISTRO_FEATURE or PACKAGECONFIG (or both, ugh). Ultimately the result is the same - distro policy controls whether this feature is on or off.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

Oh ok, I thought just about Qt + Phonon +- Pulseaudio case. If a user disables or enables Pulseaudio he would need to rebuild all Qt stuff to make it work (and building Qt is time consuming). With a separate phonon recipe he could just rebuild the libphonon recipe instead.

Quoted 2 lines · On Friday 27 January 2012 11:43:50 Samuel Stirtzel wrote:

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?

Well, this thread is now about something more fundamental (how to introduce new DISTRO_FEATURES), but we do still need to solve the problem that prompted the wider discussion. It's still possible that someone would want to build phonon without pulseaudio, even if it was split out into a separate recipe, so I'm not sure that addresses the problem.

Quoted 3 lines

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.

Pulseaudio has become an optional dependency for a lot of things. I think it makes sense to make a decision on whether or not to include this on a distro level since if you have it enabled in one place you almost certainly want it enabled everywhere else (and disabled everywhere if it is disabled).

Now, at the start of this saga there was a question as to whether this should be a DISTRO_FEATURE or PACKAGECONFIG (or both, ugh). Ultimately the result is the same - distro policy controls whether this feature is on or off.

Cheers,
Paul

Signature · 7 lines

Paul Eggleton
Intel Open Source Technology Centre

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core