[PATCH 0/3] Make pulseaudio a DISTRO_FEATURE

[PATCH 0/3] Make pulseaudio a DISTRO_FEATURE

[Paul Eggleton]

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

-- 
1.7.5.4

[PATCH 1/3] default-distrovars: add pulseaudio to DISTRO_FEATURES

[Paul Eggleton]

This adds the ability to remove pulseaudio dependencies at the
distribution level.

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/conf/distro/include/default-distrovars.inc |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/meta/conf/distro/include/default-distrovars.inc b/meta/conf/distro/include/default-distrovars.inc
index 79c6e14..20c69fe 100644
--- a/meta/conf/distro/include/default-distrovars.inc
+++ b/meta/conf/distro/include/default-distrovars.inc
@@ -16,7 +16,8 @@ DISTRO_FEATURES_LIBC ?= "ipv4 ipv6 libc-backtrace libc-big-macros libc-bsd libc-
 					libc-memusage libc-nis libc-nsswitch libc-rcmd libc-rtld-debug libc-spawn libc-streams libc-sunrpc \
 					libc-utmp libc-utmpx libc-wordexp libc-posix-clang-wchar libc-posix-regexp libc-posix-regexp-glibc \
 					libc-posix-wchar-io"
-DISTRO_FEATURES ?= "alsa argp bluetooth ext2 irda largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g x11 ${DISTRO_FEATURES_LIBC}"
+DISTRO_FEATURES ?= "alsa argp bluetooth ext2 irda largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g x11 pulseaudio \
+                    ${DISTRO_FEATURES_LIBC}"
 
 IMAGE_FEATURES ?= ""
 
-- 
1.7.5.4

[PATCH 2/3] qt4: make pulseaudio support conditional upon DISTRO_FEATURES

[Paul Eggleton]

If pulseaudio is not in DISTRO_FEATURES then disable pulseaudio support
in phonon within Qt4; otherwise it auto-detects it and it may be enabled
or disabled depending on what gets built first.

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 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 +-
 4 files changed, 52 insertions(+), 3 deletions(-)
 create mode 100644 meta/recipes-qt/qt4/files/pulseaudio-config.patch

diff --git a/meta/recipes-qt/qt4/files/pulseaudio-config.patch b/meta/recipes-qt/qt4/files/pulseaudio-config.patch
new file mode 100644
index 0000000..d5e6bc0
--- /dev/null
+++ b/meta/recipes-qt/qt4/files/pulseaudio-config.patch
@@ -0,0 +1,44 @@
+From 85f9264773407f2bf8d0495c9fc8bd83683ab2f0 Mon Sep 17 00:00:00 2001
+From: Paul Eggleton <paul.eggleton@linux.intel.com>
+Date: Wed, 23 Nov 2011 14:36:10 +0000
+Subject: [PATCH] configure: make pulseaudio a configurable option
+
+Allows disabling pulseaudio support within phonon at configure time.
+
+Upstream-Status: Pending
+
+Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
+---
+ configure |    9 ++++++++-
+ 1 files changed, 8 insertions(+), 1 deletions(-)
+
+diff --git a/configure b/configure
+index 3b7a1f3..7616fd3 100755
+--- a/configure
++++ b/configure
+@@ -941,7 +941,7 @@ while [ "$#" -gt 0 ]; do
+         VAL=no
+         ;;
+     #Qt style yes options
+-    -incremental|-qvfb|-profile|-shared|-static|-sm|-xinerama|-xshape|-xsync|-xinput|-egl|-reduce-exports|-pch|-separate-debug-info|-stl|-freetype|-xcursor|-xfixes|-xrandr|-xrender|-mitshm|-fontconfig|-xkb|-nis|-qdbus|-dbus|-dbus-linked|-glib|-gstreamer|-gtkstyle|-cups|-iconv|-largefile|-h|-help|-v|-verbose|-debug|-release|-fast|-accessibility|-confirm-license|-gnumake|-framework|-qt3support|-debug-and-release|-exceptions|-cocoa|-carbon|-universal|-prefix-install|-silent|-armfpa|-optimized-qmake|-dwarf2|-reduce-relocations|-sse|-openssl|-openssl-linked|-ptmalloc|-xmlpatterns|-phonon|-phonon-backend|-multimedia|-audio-backend|-svg|-declarative|-declarative-debug|-javascript-jit|-script|-scripttools|-rpath|-force-pkg-config|-s60|-usedeffiles)
++    -incremental|-qvfb|-profile|-shared|-static|-sm|-xinerama|-xshape|-xsync|-xinput|-egl|-reduce-exports|-pch|-separate-debug-info|-stl|-freetype|-xcursor|-xfixes|-xrandr|-xrender|-mitshm|-fontconfig|-xkb|-nis|-qdbus|-dbus|-dbus-linked|-glib|-gstreamer|-pulseaudio|-gtkstyle|-cups|-iconv|-largefile|-h|-help|-v|-verbose|-debug|-release|-fast|-accessibility|-confirm-license|-gnumake|-framework|-qt3support|-debug-and-release|-exceptions|-cocoa|-carbon|-universal|-prefix-install|-silent|-armfpa|-optimized-qmake|-dwarf2|-reduce-relocations|-sse|-openssl|-openssl-linked|-ptmalloc|-xmlpatterns|-phonon|-phonon-backend|-multimedia|-audio-backend|-svg|-declarative|-declarative-debug|-javascript-jit|-script|-scripttools|-rpath|-force-pkg-config|-s60|-usedeffiles)
+         VAR=`echo $1 | sed "s,^-\(.*\),\1,"`
+         VAL=yes
+         ;;
+@@ -1863,6 +1863,13 @@ while [ "$#" -gt 0 ]; do
+             UNKNOWN_OPT=yes
+         fi
+         ;;
++    pulseaudio)
++        if [ "$VAL" = "yes" ] || [ "$VAL" = "no" ]; then
++            CFG_PULSEAUDIO="$VAL"
++        else
++            UNKNOWN_OPT=yes
++        fi
++        ;;
+     gtkstyle)
+         if [ "$VAL" = "yes" ] || [ "$VAL" = "no" ]; then
+             CFG_QGTKSTYLE="$VAL"
+-- 
+1.7.5.4
+
diff --git a/meta/recipes-qt/qt4/qt-4.7.4.inc b/meta/recipes-qt/qt4/qt-4.7.4.inc
index bc33b6b..171a7a1 100644
--- a/meta/recipes-qt/qt4/qt-4.7.4.inc
+++ b/meta/recipes-qt/qt4/qt-4.7.4.inc
@@ -3,6 +3,8 @@ LIC_FILES_CHKSUM = "file://LICENSE.LGPL;md5=fbc093901857fcd118f065f900982c24 \
                     file://LICENSE.GPL3;md5=babc5b6b77441da277f5c06b2e547720 \
                     file://LGPL_EXCEPTION.txt;md5=411080a56ff917a5a1aa08c98acae354"
 
+DEPENDS += "${@base_contains('DISTRO_FEATURES', 'pulseaudio', 'pulseaudio', '', d)}"
+
 FILESPATH =. "${FILE_DIRNAME}/qt-${PV}:"
 
 SRC_URI = "http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-${PV}.tar.gz \
@@ -17,6 +19,7 @@ SRC_URI = "http://get.qt.nokia.com/qt/source/qt-everywhere-opensource-src-${PV}.
            file://g++.conf \
            file://linux.conf \
            file://fix-qtbug-20925.patch \
+           file://pulseaudio-config.patch \
            "
 
 SRC_URI[md5sum] = "9831cf1dfa8d0689a06c2c54c5c65aaf"
@@ -43,7 +46,9 @@ do_configure_prepend() {
 }
 
 QT_GLFLAGS ?= ""
-QT_CONFIG_FLAGS += " -xmlpatterns -no-rpath -qt3support -reduce-relocations -silent ${QT_GLFLAGS}"
+QT_CONFIG_FLAGS += "-xmlpatterns -no-rpath -qt3support -reduce-relocations \
+                    ${@base_contains('DISTRO_FEATURES', 'pulseaudio', '--enable-pulseaudio', '--disable-pulseaudio', d)} \
+                    -silent ${QT_GLFLAGS}"
 
 do_compile() {
     # Fixup missing wsegl header in some SGX SDKs
diff --git a/meta/recipes-qt/qt4/qt4-embedded_4.7.4.bb b/meta/recipes-qt/qt4/qt4-embedded_4.7.4.bb
index e34ec8d..6b9f97a 100644
--- a/meta/recipes-qt/qt4/qt4-embedded_4.7.4.bb
+++ b/meta/recipes-qt/qt4/qt4-embedded_4.7.4.bb
@@ -1,7 +1,7 @@
 require qt-${PV}.inc
 require qt4-embedded.inc
 
-PR = "${INC_PR}.3"
+PR = "${INC_PR}.4"
 
 QT_CONFIG_FLAGS_append_armv6-vfp = " -no-neon "
 
diff --git a/meta/recipes-qt/qt4/qt4-x11-free_4.7.4.bb b/meta/recipes-qt/qt4/qt4-x11-free_4.7.4.bb
index 8c48936..0db090f 100644
--- a/meta/recipes-qt/qt4/qt4-x11-free_4.7.4.bb
+++ b/meta/recipes-qt/qt4/qt4-x11-free_4.7.4.bb
@@ -1,7 +1,7 @@
 require qt4-x11-free.inc
 require qt-${PV}.inc
 
-PR = "${INC_PR}.3"
+PR = "${INC_PR}.4"
 
 QT_CONFIG_FLAGS_append_armv6-vfp = " -no-neon "
 
-- 
1.7.5.4

[PATCH 3/3] gst-plugins-good: make pulseaudio support conditional upon DISTRO_FEATURES

[Paul Eggleton]

Allow pulseaudio support to be disabled at a distro level rather than
always being enabled.

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 .../gstreamer/gst-plugins-good_0.10.30.bb          |    8 +++++---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.30.bb b/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.30.bb
index 728175b..506c581 100644
--- a/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.30.bb
+++ b/meta/recipes-multimedia/gstreamer/gst-plugins-good_0.10.30.bb
@@ -6,12 +6,14 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=a6f89e2100d9b6cdffcea4f398e37343 \
                     file://gst/replaygain/rganalysis.c;beginline=1;endline=23;md5=b60ebefd5b2f5a8e0cab6bfee391a5fe"
 
 DEPENDS += "gst-plugins-base gconf cairo jpeg libpng gtk+ zlib libid3tag flac \
-	    speex libsoup-2.4 pulseaudio"
-PR = "r3"
+            speex libsoup-2.4 \
+            ${@base_contains('DISTRO_FEATURES', 'pulseaudio', 'pulseaudio', '', d)}"
+PR = "r4"
 
 inherit gettext gconf
 
-EXTRA_OECONF += "--disable-aalib --disable-esd --disable-shout2 --disable-libcaca --disable-hal --without-check"
+EXTRA_OECONF += "--disable-aalib --disable-esd --disable-shout2 --disable-libcaca --disable-hal --without-check \
+                 ${@base_contains('DISTRO_FEATURES', 'pulseaudio', '--enable-pulseaudio', '--disable-pulseaudio', d)}"
 
 do_configure_prepend() {
 	# This m4 file contains nastiness which conflicts with libtool 2.2.2
-- 
1.7.5.4

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

[Koen Kooi]

[-- Attachment #1: Type: text/plain, Size: 1443 bytes --]


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

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

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

[Paul Eggleton]

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

-- 

Paul Eggleton
Intel Open Source Technology Centre

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

[Phil Blundell]

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.

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

[Richard Purdie]

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

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

[Paul Eggleton]

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
Intel Open Source Technology Centre

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

[Paul Eggleton]

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

-- 

Paul Eggleton
Intel Open Source Technology Centre

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

[Phil Blundell]

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.

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

[Otavio Salvador]

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

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.


-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

[-- Attachment #2: Type: text/html, Size: 1272 bytes --]

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

[Paul Eggleton]

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
Intel Open Source Technology Centre

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

[Paul Eggleton]

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

-- 

Paul Eggleton
Intel Open Source Technology Centre

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

[Phil Blundell]

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.

Process for New DISTRO_FEATURES (was: Re: [PATCH 0/3] Make pulseaudio a DISTRO_FEATURE)

[Richard Purdie]

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

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

[Tom Rini]

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

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

[Samuel Stirtzel]

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


-- 
Regards
Samuel

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

[Paul Eggleton]

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

-- 

Paul Eggleton
Intel Open Source Technology Centre

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

[Samuel Stirtzel]

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



-- 
Regards
Samuel

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

[Paul Eggleton]

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

-- 

Paul Eggleton
Intel Open Source Technology Centre

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

[Khem Raj]

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

-- 
-Khem