Patchwork [0/3] Make pulseaudio a DISTRO_FEATURE

login
register
mail settings
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-pulseaudio

Comments

Paul Eggleton - Nov. 23, 2011, 3:32 p.m.
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
Koen Kooi - Nov. 23, 2011, 3:59 p.m.
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
Paul Eggleton - Nov. 23, 2011, 4:33 p.m.
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
Phil Blundell - Nov. 23, 2011, 4:48 p.m.
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.
Richard Purdie - Nov. 23, 2011, 5:09 p.m.
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
Paul Eggleton - Nov. 23, 2011, 5:45 p.m.
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
Paul Eggleton - Nov. 23, 2011, 5:49 p.m.
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
Phil Blundell - Nov. 23, 2011, 5:53 p.m.
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.
Otavio Salvador - Nov. 23, 2011, 6:22 p.m.
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.
Paul Eggleton - Dec. 29, 2011, 12:55 p.m.
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
Paul Eggleton - Jan. 16, 2012, 5:58 p.m.
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
Phil Blundell - Jan. 16, 2012, 6:12 p.m.
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.
Tom Rini - Jan. 17, 2012, 8:02 p.m.
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.
Richard Purdie - Jan. 17, 2012, 11:13 p.m.
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
Samuel Stirtzel - Jan. 27, 2012, 10:43 a.m.
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
Paul Eggleton - Jan. 27, 2012, 10:54 a.m.
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
Samuel Stirtzel - Jan. 27, 2012, 11:34 a.m.
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
Paul Eggleton - Jan. 27, 2012, 12:13 p.m.
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
Khem Raj - Jan. 28, 2012, 8:05 p.m.
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