| Submitter | Paul Eggleton |
|---|---|
| Date | Nov. 23, 2011, 3:32 p.m. |
| Message ID | <cover.1322061836.git.paul.eggleton@linux.intel.com> |
| Download | mbox |
| Permalink | /patch/15335/ |
| State | New |
| Headers | show |
Pull-request
git://git.openembedded.org/openembedded-core-contrib paule/qt4-pulseaudioComments
Op 23 nov. 2011, om 16:32 heeft Paul Eggleton het volgende geschreven: > 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, The phonon backends (e.g. gstreamer) are nicely modularized is the pulseaudio case different? > 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. 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 :) regards, Koen
On Wednesday 23 November 2011 16:59:56 Koen Kooi wrote: > The phonon backends (e.g. gstreamer) are nicely modularized is the > pulseaudio case different? Unfortunately yes, since libphonon.so.* itself becomes linked to several pulseaudio shared libraries when it is enabled at configure time. > 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 :) 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. Cheers, Paul
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. p.
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
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. > > 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. 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. 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? That would avoid breakage over time in a much simpler way than the above, IMHO. (I'm aware that we have oe_filter_out but I think that's a bit untidy.) Cheers, Paul
On Wednesday 23 November 2011 17:45:35 Paul Eggleton wrote: > In that case, should we > not be providing the appropriate mechanism so that can exclude the features That should have been "...so that distros can...", sorry. Cheers, Paul
On Wed, 2011-11-23 at 17:45 +0000, Paul Eggleton wrote: > 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. I'm not sure that this is true. There are several recent(ish) examples of DISTRO_FEATURES that are for new things (e.g. directfb as the base graphics layer, or gold as the linker), rather than just turning off switches that were previously the default. And... >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? ... it seems as though this is basically equivalent to the "nopulseaudio" proposal, and would suck for the same reasons. >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. I'm not quite sure I understand what you're saying here. Richard's proposal, if I understand it right, is basically giving DISTROs a way to say "these are the features that I know about and have decided I don't want" so that the compatibility code can give them sensible defaults for the features that they aren't aware of. It's true that this will (in some sense) segment them into "new" and "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. p.
On Wed, Nov 23, 2011 at 15:53, Phil Blundell <philb@gnu.org> wrote: > ... > It's true that this will (in some sense) segment them into "new" and > "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. In this case I think distros can live with those new features and deal with it.
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
On Thursday 29 December 2011 12:55:56 Paul Eggleton 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. 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? Cheers, Paul
On Mon, 2012-01-16 at 17:58 +0000, Paul Eggleton wrote: > On Thursday 29 December 2011 12:55:56 Paul Eggleton wrote: > > 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. > > > > > > 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. > > 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? Personally I prefer option (a) and Richard's terminology. I think the "introduce" naming is a bit too vague and generic and doesn't really capture what's going on here. p.
On Thu, Dec 29, 2011 at 5:55 AM, Paul Eggleton <paul.eggleton@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.
On Mon, 2012-01-16 at 17:58 +0000, Paul Eggleton wrote: > On Thursday 29 December 2011 12:55:56 Paul Eggleton 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. > > 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? In the intervening time I haven't come up with anything better. I would like to move forward on this issue. I think the main thing is to document the variables clearly. The names aren't brilliant but with reasonable comments we should be ok... Cheers, Richard
2012/1/17 Tom Rini <tom.rini@gmail.com>: > On Thu, Dec 29, 2011 at 5:55 AM, Paul Eggleton > <paul.eggleton@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@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
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. > 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
2012/1/27 Paul Eggleton <paul.eggleton@linux.intel.com>: > 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. 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. > >> 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). So it's not just Phonon depending on Pulseaudio, then I see the comfort of a distro level switch. > > 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
On Friday 27 January 2012 12:34:59 Samuel Stirtzel wrote: > 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. Whilst this might seem attractive, I don't believe encouraging people to play with DISTRO_FEATURES *after* they have built things is a good idea - these should really be set beforehand and not changed without rebuilding everything. Otherwise we're setting users up for unexpected and difficult to debug failures. (Of course that assumes the user knows and appreciates the implications of items in DISTRO_FEATURES, and we may need to improve our tooling and documentation such that they can, should they even need to change them that is.) Cheers, Paul
On (27/01/12 10:54), Paul Eggleton wrote: > 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. > > > 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. DISTRO_FEATURES are like global use_flags equivalent of gentoo and PACKAGECONFIG is more like local use_flags. Sometimes DISTRO_FEATURES will configure particular PACKAGECONFIG settings and sometimes you can just tweak the PACKAGECONFIG > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
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 following changes since commit aaa2a70f7f1b8a299f31626d61d7ea27f29fb9e2: gconf: Ensure the correct backend directory is used (2011-11-23 15:10:41 +0000) are available in the git repository at: git://git.openembedded.org/openembedded-core-contrib paule/qt4-pulseaudio http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/qt4-pulseaudio Paul Eggleton (3): default-distrovars: add pulseaudio to DISTRO_FEATURES qt4: make pulseaudio support conditional upon DISTRO_FEATURES gst-plugins-good: make pulseaudio support conditional upon DISTRO_FEATURES meta/conf/distro/include/default-distrovars.inc | 3 +- .../gstreamer/gst-plugins-good_0.10.30.bb | 8 ++- meta/recipes-qt/qt4/files/pulseaudio-config.patch | 44 ++++++++++++++++++++ meta/recipes-qt/qt4/qt-4.7.4.inc | 7 +++- meta/recipes-qt/qt4/qt4-embedded_4.7.4.bb | 2 +- meta/recipes-qt/qt4/qt4-x11-free_4.7.4.bb | 2 +- 6 files changed, 59 insertions(+), 7 deletions(-) create mode 100644 meta/recipes-qt/qt4/files/pulseaudio-config.patch