[RFC][PATCH 0/5] drop dependency on GNOME if x11 is disabled

[RFC][PATCH 0/5] drop dependency on GNOME if x11 is disabled

[Andreas Oberritter]

I'd like to stop various GNOME packages from being built in a
distro which doesn't use x11. For me, this fixes many unwanted
dependencies, e.g. librsvg -> gconf -> polkit -> systemd -> udev-systemd
on a system with an old kernel (2.6.18), which cannot use a recent
udev. Of course, it saves some build time, too.

I guess, additional PR bumps for all users of gconf, gnomebase and
gtk-icon-cache bbclasses are required in order to pick up this change,
right? Does someone already have a script to automatically generate
a list of affected recipes? Is the PR bump required, considering that
this change mainly reduces build-time dependencies? It also disables
some preinst and postrm hooks, but they don't really hurt on existing
images. I suppose there aren't many images using GNOME packages
without x11. Any opinions?

Is it OK to use the 'x11' flag for this purpose? Is anybody using
GNOME with a different backend? Would it be better to introduce
a 'gnome' (and 'gconf'?) distro feature flag?

Regards,
Andreas

Andreas Oberritter (5):
  libsoup-2.4: don't depend on libgnome-keyring unless x11 is defined
  libproxy: don't depend on gconf unless x11 is defined
  gconf.bbclass: don't add dependencies or hooks unless x11 is defined
  gtk-icon-cache.bbclass: don't add dependencies or hooks unless x11 is
    defined
  gnomebase.bbclass: skip packages inheriting gnomebase unless x11 is
    defined

 meta/classes/gconf.bbclass                         |    5 ++++-
 meta/classes/gnomebase.bbclass                     |    7 ++++++-
 meta/classes/gtk-icon-cache.bbclass                |    5 ++++-
 meta/recipes-support/libproxy/libproxy_0.4.7.bb    |    4 ++--
 meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb |    4 ++--
 5 files changed, 18 insertions(+), 7 deletions(-)

-- 
1.7.5.4

[PATCH 1/5] libsoup-2.4: don't depend on libgnome-keyring unless x11 is defined

[Andreas Oberritter]

* Drop dependency on GNOME if x11 is disabled.

Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
---
 meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb b/meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb
index 8e6ef26..861a1aa 100644
--- a/meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb
+++ b/meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb
@@ -6,9 +6,9 @@ LICENSE = "LGPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=5f30f0716dfdd0d91eb439ebec522ec2"
 
 SECTION = "x11/gnome/libs"
-PR = "r1"
+PR = "r2"
 
-DEPENDS = "glib-2.0 gnutls libxml2 libproxy sqlite3 libgnome-keyring"
+DEPENDS = "glib-2.0 gnutls libxml2 libproxy sqlite3 ${@base_contains('DISTRO_FEATURES', 'x11', 'libgnome-keyring', '', d)}"
 
 SRC_URI = "${GNOME_MIRROR}/libsoup/2.36/libsoup-${PV}.tar.bz2"
 
-- 
1.7.5.4

[PATCH 2/5] libproxy: don't depend on gconf unless x11 is defined

[Andreas Oberritter]

* Drop dependency on GNOME if x11 is disabled.

Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
---
 meta/recipes-support/libproxy/libproxy_0.4.7.bb |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-support/libproxy/libproxy_0.4.7.bb b/meta/recipes-support/libproxy/libproxy_0.4.7.bb
index f31b701..659100d 100644
--- a/meta/recipes-support/libproxy/libproxy_0.4.7.bb
+++ b/meta/recipes-support/libproxy/libproxy_0.4.7.bb
@@ -6,9 +6,9 @@ LICENSE = "LGPLv2.1+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=7d7044444a7b1b116e8783edcdb44ff4 \
                     file://utils/proxy.c;beginline=1;endline=18;md5=55152a1006d7dafbef32baf9c30a99c0"
 
-DEPENDS = "gconf"
+DEPENDS = "${@base_contains('DISTRO_FEATURES', 'x11', 'gconf', '', d)}"
 
-PR = "r1"
+PR = "r2"
 
 SRC_URI = "http://libproxy.googlecode.com/files/libproxy-${PV}.tar.gz"
 
-- 
1.7.5.4

[PATCH 3/5] gconf.bbclass: don't add dependencies or hooks unless x11 is defined

[Andreas Oberritter]

* Drop dependency on GNOME if x11 is disabled.

Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
---
 meta/classes/gconf.bbclass |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/meta/classes/gconf.bbclass b/meta/classes/gconf.bbclass
index 7bfa871..5067abd 100644
--- a/meta/classes/gconf.bbclass
+++ b/meta/classes/gconf.bbclass
@@ -1,4 +1,4 @@
-DEPENDS += "gconf gconf-native"
+DEPENDS += "${@base_contains('DISTRO_FEATURES', 'x11', 'gconf gconf-native', '', d)}"
 
 # This is referenced by the gconf m4 macros and would default to the value hardcoded
 # into gconf at compile time otherwise
@@ -31,6 +31,9 @@ done
 }
 
 python populate_packages_append () {
+	if not oe.utils.contains('DISTRO_FEATURES', 'x11', True, False, d):
+		return
+
 	import re
 	packages = d.getVar('PACKAGES', 1).split()
 	pkgdest =  d.getVar('PKGDEST', 1)
-- 
1.7.5.4

[PATCH 4/5] gtk-icon-cache.bbclass: don't add dependencies or hooks unless x11 is defined

[Andreas Oberritter]

* Drop dependency on GNOME if x11 is disabled.

Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
---
 meta/classes/gtk-icon-cache.bbclass |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/meta/classes/gtk-icon-cache.bbclass b/meta/classes/gtk-icon-cache.bbclass
index 0204fd3..cf5907b 100644
--- a/meta/classes/gtk-icon-cache.bbclass
+++ b/meta/classes/gtk-icon-cache.bbclass
@@ -1,6 +1,6 @@
 FILES_${PN} += "${datadir}/icons/hicolor"
 
-DEPENDS += "${@['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme']}"
+DEPENDS += "${@base_contains('DISTRO_FEATURES', 'x11', ['hicolor-icon-theme', '']['${BPN}' == 'hicolor-icon-theme'], '', d)}"
 
 # This could run on the host as icon cache files are architecture independent,
 # but there is no gtk-update-icon-cache built natively.
@@ -28,6 +28,9 @@ done
 }
 
 python populate_packages_append () {
+	if not oe.utils.contains('DISTRO_FEATURES', 'x11', True, False, d):
+		return
+
 	packages = d.getVar('PACKAGES', 1).split()
 	pkgdest =  d.getVar('PKGDEST', 1)
 	
-- 
1.7.5.4

[PATCH 5/5] gnomebase.bbclass: skip packages inheriting gnomebase unless x11 is defined

[Andreas Oberritter]

* Drop dependency on GNOME if x11 is disabled.
* Exceptions may be listed in a whitelist.
* Current exceptions are: libcroco, librsvg and pango.

Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
---
 meta/classes/gnomebase.bbclass |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

diff --git a/meta/classes/gnomebase.bbclass b/meta/classes/gnomebase.bbclass
index a4209a0..f81d79b 100644
--- a/meta/classes/gnomebase.bbclass
+++ b/meta/classes/gnomebase.bbclass
@@ -6,7 +6,7 @@ def gnome_verdir(v):
 SECTION ?= "x11/gnome"
 SRC_URI = "${GNOME_MIRROR}/${BPN}/${@gnome_verdir("${PV}")}/${BPN}-${PV}.tar.bz2;name=archive"
 
-DEPENDS += "gnome-common"
+DEPENDS += "${@base_contains('DISTRO_FEATURES', 'x11', 'gnome-common', '', d)}"
 
 FILES_${PN} += "${datadir}/application-registry  \
 	${datadir}/mime-info \
@@ -28,3 +28,8 @@ do_install_append() {
 	rm -f ${D}${datadir}/applications/*.cache
 }
 
+python () {
+        whitelist = [ "libcroco", "librsvg", "pango" ]
+        if not d.getVar('BPN', True) in whitelist and not oe.utils.contains ('DISTRO_FEATURES', 'x11', True, False, d):
+                raise bb.parse.SkipPackage("'x11' not in DISTRO_FEATURES")
+}
-- 
1.7.5.4

Re: [PATCH 1/5] libsoup-2.4: don't depend on libgnome-keyring unless x11 is defined

[Koen Kooi]

Op 22 feb. 2012, om 12:26 heeft Andreas Oberritter het volgende geschreven:

> * Drop dependency on GNOME if x11 is disabled.
> 
> Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
> ---
> meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb |    4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb b/meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb
> index 8e6ef26..861a1aa 100644
> --- a/meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb
> +++ b/meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb
> @@ -6,9 +6,9 @@ LICENSE = "LGPLv2"
> LIC_FILES_CHKSUM = "file://COPYING;md5=5f30f0716dfdd0d91eb439ebec522ec2"
> 
> SECTION = "x11/gnome/libs"
> -PR = "r1"
> +PR = "r2"
> 
> -DEPENDS = "glib-2.0 gnutls libxml2 libproxy sqlite3 libgnome-keyring"
> +DEPENDS = "glib-2.0 gnutls libxml2 libproxy sqlite3 ${@base_contains('DISTRO_FEATURES', 'x11', 'libgnome-keyring', '', d)}"

that one likely needs a --disable-something to be deterministic.

regards,

Koen

Re: [PATCH 2/5] libproxy: don't depend on gconf unless x11 is defined

[Koen Kooi]

Op 22 feb. 2012, om 12:26 heeft Andreas Oberritter het volgende geschreven:

> * Drop dependency on GNOME if x11 is disabled.
> 
> Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
> ---
> meta/recipes-support/libproxy/libproxy_0.4.7.bb |    4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-support/libproxy/libproxy_0.4.7.bb b/meta/recipes-support/libproxy/libproxy_0.4.7.bb
> index f31b701..659100d 100644
> --- a/meta/recipes-support/libproxy/libproxy_0.4.7.bb
> +++ b/meta/recipes-support/libproxy/libproxy_0.4.7.bb
> @@ -6,9 +6,9 @@ LICENSE = "LGPLv2.1+"
> LIC_FILES_CHKSUM = "file://COPYING;md5=7d7044444a7b1b116e8783edcdb44ff4 \
>                     file://utils/proxy.c;beginline=1;endline=18;md5=55152a1006d7dafbef32baf9c30a99c0"
> 
> -DEPENDS = "gconf"
> +DEPENDS = "${@base_contains('DISTRO_FEATURES', 'x11', 'gconf', '', d)}"

that one likely needs a --disable-something to be deterministic.

regards,

Koen

Re: [RFC][PATCH 0/5] drop dependency on GNOME if x11 is disabled

[Richard Purdie]

On Wed, 2012-02-22 at 12:26 +0100, Andreas Oberritter wrote:
> I'd like to stop various GNOME packages from being built in a
> distro which doesn't use x11. For me, this fixes many unwanted
> dependencies, e.g. librsvg -> gconf -> polkit -> systemd -> udev-systemd
> on a system with an old kernel (2.6.18), which cannot use a recent
> udev. Of course, it saves some build time, too.

That dependency doesn't exist in OE-Core FWIW.

> I guess, additional PR bumps for all users of gconf, gnomebase and
> gtk-icon-cache bbclasses are required in order to pick up this change,
> right?

This is one of the few cases I'm tempted to say no, its not required.

>  Does someone already have a script to automatically generate
> a list of affected recipes? Is the PR bump required, considering that
> this change mainly reduces build-time dependencies?

The plan is to rely on sstate's hash changes and the OEBasicHash
signature generator for this in future.

>  It also disables
> some preinst and postrm hooks, but they don't really hurt on existing
> images.

I'd suggest for these we modify them to only run if the appropriate
executables are present. If not present, then it won't hurt anything.

>  I suppose there aren't many images using GNOME packages
> without x11. Any opinions?
> 
> Is it OK to use the 'x11' flag for this purpose? Is anybody using
> GNOME with a different backend? Would it be better to introduce
> a 'gnome' (and 'gconf'?) distro feature flag?

I looked at these patches and my conclusion was no, the x11 flag is not
appropriate in this context.

Why? It would break gtk+ compiled against directfb for example. In the
future we'll likely have a similar issue if gtk+ is compiled against
something like wayland.

I also don't like "gnome" since you are using some gnome packages.
Specifically, you seem to want to avoid gtk and gconf. So all things
considered this needs a bit more discussion...

Cheers,

Richard

Re: [RFC][PATCH 0/5] drop dependency on GNOME if x11 is disabled

[Andreas Oberritter]

On 22.02.2012 14:31, Richard Purdie wrote:
> On Wed, 2012-02-22 at 12:26 +0100, Andreas Oberritter wrote:
>> I'd like to stop various GNOME packages from being built in a
>> distro which doesn't use x11. For me, this fixes many unwanted
>> dependencies, e.g. librsvg -> gconf -> polkit -> systemd -> udev-systemd
>> on a system with an old kernel (2.6.18), which cannot use a recent
>> udev. Of course, it saves some build time, too.
> 
> That dependency doesn't exist in OE-Core FWIW.

Yes, this is caused by meta-oe.

>> I guess, additional PR bumps for all users of gconf, gnomebase and
>> gtk-icon-cache bbclasses are required in order to pick up this change,
>> right?
> 
> This is one of the few cases I'm tempted to say no, its not required.
> 
>>  Does someone already have a script to automatically generate
>> a list of affected recipes? Is the PR bump required, considering that
>> this change mainly reduces build-time dependencies?
> 
> The plan is to rely on sstate's hash changes and the OEBasicHash
> signature generator for this in future.
> 
>>  It also disables
>> some preinst and postrm hooks, but they don't really hurt on existing
>> images.
> 
> I'd suggest for these we modify them to only run if the appropriate
> executables are present. If not present, then it won't hurt anything.

OK. The small downside is that those hooks can't run at rootfs creation
time. Is there a "best practice" to check the existence of an executable
in $PATH from such a hook?

>>  I suppose there aren't many images using GNOME packages
>> without x11. Any opinions?
>>
>> Is it OK to use the 'x11' flag for this purpose? Is anybody using
>> GNOME with a different backend? Would it be better to introduce
>> a 'gnome' (and 'gconf'?) distro feature flag?
> 
> I looked at these patches and my conclusion was no, the x11 flag is not
> appropriate in this context.
> 
> Why? It would break gtk+ compiled against directfb for example. In the
> future we'll likely have a similar issue if gtk+ is compiled against
> something like wayland.

Gtk+ on directfb still built fine with these patches. Does it need
hicolor-icon-theme to run? In this case, RDEPENDS should be added to
gtk+, I guess. I don't see anything else possibly causing breakage.

Nevertheless, I understand that 'x11' isn't appropriate. The upside of
using 'x11' was that it wouldn't break distributions, like new flags
would do.

> I also don't like "gnome" since you are using some gnome packages.
> Specifically, you seem to want to avoid gtk and gconf. So all things
> considered this needs a bit more discussion...

Actually, I don't really need gtk+ either, but I'd still like to make it
available to our customers on the online feed.

To be more specific, I'd like to disable GNOME infrastructure, not
necessarily all GNOME libraries. In other words, I'd like to keep those
libs that, though being hosted on gnome.org as part of the GNOME
project, don't depend on other GNOME (UI) libraries etc.). For example,
I'd like to use gstreamer, which depends on libsoup and librsvg, without
introducing unnecessary dependencies on gconf, gconf-native,
gnome-common, hicolor-icon-theme and libgnome-keyring and all of their
own dependencies.

So how about 'gconf' and 'gnome-ui' as new distro features? Actually I
proposed 'gnome', because all modified bbclasses get inherited by
gnome.bbclass.

Regards,
Andreas

Re: [RFC][PATCH 0/5] drop dependency on GNOME if x11 is disabled

[Paul Eggleton]

On Wednesday 22 February 2012 15:54:09 Andreas Oberritter wrote:
> Nevertheless, I understand that 'x11' isn't appropriate. The upside of
> using 'x11' was that it wouldn't break distributions, like new flags
> would do.

Incidentally, I sent an RFC patch yesterday to add a mechanism to make it 
possible to add new DISTRO_FEATURES without breaking existing distro 
configurations. So far I haven't had any comments.
 
Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [RFC][PATCH 0/5] drop dependency on GNOME if x11 is disabled

[Richard Purdie]

On Wed, 2012-02-22 at 15:54 +0100, Andreas Oberritter wrote:
> On 22.02.2012 14:31, Richard Purdie wrote:
> > On Wed, 2012-02-22 at 12:26 +0100, Andreas Oberritter wrote:
> >>  It also disables
> >> some preinst and postrm hooks, but they don't really hurt on existing
> >> images.
> > 
> > I'd suggest for these we modify them to only run if the appropriate
> > executables are present. If not present, then it won't hurt anything.
> 
> OK. The small downside is that those hooks can't run at rootfs creation
> time. Is there a "best practice" to check the existence of an executable
> in $PATH from such a hook?

"which xxx"?

> >>  I suppose there aren't many images using GNOME packages
> >> without x11. Any opinions?
> >>
> >> Is it OK to use the 'x11' flag for this purpose? Is anybody using
> >> GNOME with a different backend? Would it be better to introduce
> >> a 'gnome' (and 'gconf'?) distro feature flag?
> > 
> > I looked at these patches and my conclusion was no, the x11 flag is not
> > appropriate in this context.
> > 
> > Why? It would break gtk+ compiled against directfb for example. In the
> > future we'll likely have a similar issue if gtk+ is compiled against
> > something like wayland.
> 
> Gtk+ on directfb still built fine with these patches. Does it need
> hicolor-icon-theme to run? In this case, RDEPENDS should be added to
> gtk+, I guess. I don't see anything else possibly causing breakage.

I was thinking gtk+ would use the gnome classes too which upon
inspection it does not.

> Nevertheless, I understand that 'x11' isn't appropriate. The upside of
> using 'x11' was that it wouldn't break distributions, like new flags
> would do.

Paul has a patch out to help with this problem.

> > I also don't like "gnome" since you are using some gnome packages.
> > Specifically, you seem to want to avoid gtk and gconf. So all things
> > considered this needs a bit more discussion...
> 
> Actually, I don't really need gtk+ either, but I'd still like to make it
> available to our customers on the online feed.
> 
> To be more specific, I'd like to disable GNOME infrastructure, not
> necessarily all GNOME libraries. In other words, I'd like to keep those
> libs that, though being hosted on gnome.org as part of the GNOME
> project, don't depend on other GNOME (UI) libraries etc.). For example,
> I'd like to use gstreamer, which depends on libsoup and librsvg, without
> introducing unnecessary dependencies on gconf, gconf-native,
> gnome-common, hicolor-icon-theme and libgnome-keyring and all of their
> own dependencies.
> 
> So how about 'gconf' and 'gnome-ui' as new distro features? Actually I
> proposed 'gnome', because all modified bbclasses get inherited by
> gnome.bbclass.

What is really worrying me here is this is very specific to your
projects usecase. There will be others who'd expect gtk+ to be excluded
from "gnome-ui" for example. This is just the simplest case I can find
but there are other issues and we need generic code for oe-core.

I'm starting to wonder if these shouldn't be PACKAGECONFIG options for
the individual packages which you as a distro would then override the
defaults for.

You could also put some of these exclusions in your distro config. You
can check for recipes which inherit gnomebase
(bb.data.inherits("gnomebase", d)) and then run your skip package there
if the PN list doesn't match.

The main problem is I can't come up with a good flag that describes the
package set you want to exlcude, it really is rather custom to what
you're doing.

Cheers,

Richard

Re: [RFC][PATCH 0/5] drop dependency on GNOME if x11 is disabled

[Andreas Oberritter]

On 22.02.2012 22:24, Richard Purdie wrote:
> On Wed, 2012-02-22 at 15:54 +0100, Andreas Oberritter wrote:
>> On 22.02.2012 14:31, Richard Purdie wrote:
>>> On Wed, 2012-02-22 at 12:26 +0100, Andreas Oberritter wrote:
>>>>  It also disables
>>>> some preinst and postrm hooks, but they don't really hurt on existing
>>>> images.
>>>
>>> I'd suggest for these we modify them to only run if the appropriate
>>> executables are present. If not present, then it won't hurt anything.
>>
>> OK. The small downside is that those hooks can't run at rootfs creation
>> time. Is there a "best practice" to check the existence of an executable
>> in $PATH from such a hook?
> 
> "which xxx"?

Thanks! That was probably too obvious. ;-)

>>>>  I suppose there aren't many images using GNOME packages
>>>> without x11. Any opinions?
>>>>
>>>> Is it OK to use the 'x11' flag for this purpose? Is anybody using
>>>> GNOME with a different backend? Would it be better to introduce
>>>> a 'gnome' (and 'gconf'?) distro feature flag?
>>>
>>> I looked at these patches and my conclusion was no, the x11 flag is not
>>> appropriate in this context.
>>>
>>> Why? It would break gtk+ compiled against directfb for example. In the
>>> future we'll likely have a similar issue if gtk+ is compiled against
>>> something like wayland.
>>
>> Gtk+ on directfb still built fine with these patches. Does it need
>> hicolor-icon-theme to run? In this case, RDEPENDS should be added to
>> gtk+, I guess. I don't see anything else possibly causing breakage.
> 
> I was thinking gtk+ would use the gnome classes too which upon
> inspection it does not.
> 
>> Nevertheless, I understand that 'x11' isn't appropriate. The upside of
>> using 'x11' was that it wouldn't break distributions, like new flags
>> would do.
> 
> Paul has a patch out to help with this problem.

Yes. I've seen the patch and I'd be happy to use it in case it's
eventually going to be merged.

>>> I also don't like "gnome" since you are using some gnome packages.
>>> Specifically, you seem to want to avoid gtk and gconf. So all things
>>> considered this needs a bit more discussion...
>>
>> Actually, I don't really need gtk+ either, but I'd still like to make it
>> available to our customers on the online feed.
>>
>> To be more specific, I'd like to disable GNOME infrastructure, not
>> necessarily all GNOME libraries. In other words, I'd like to keep those
>> libs that, though being hosted on gnome.org as part of the GNOME
>> project, don't depend on other GNOME (UI) libraries etc.). For example,
>> I'd like to use gstreamer, which depends on libsoup and librsvg, without
>> introducing unnecessary dependencies on gconf, gconf-native,
>> gnome-common, hicolor-icon-theme and libgnome-keyring and all of their
>> own dependencies.
>>
>> So how about 'gconf' and 'gnome-ui' as new distro features? Actually I
>> proposed 'gnome', because all modified bbclasses get inherited by
>> gnome.bbclass.
> 
> What is really worrying me here is this is very specific to your
> projects usecase.

Maybe. I'd be interested in other people's opinions, especially of those
who don't use x11 et al.

> There will be others who'd expect gtk+ to be excluded
> from "gnome-ui" for example. This is just the simplest case I can find
> but there are other issues and we need generic code for oe-core.

I don't think so. Gtk+ has never had any dependency on GNOME. The latter
is built upon Gtk+, just like KDE builds upon Qt. Nobody would expect Qt
to be excluded from builds if a 'kde' flag existed and was disabled.

Regarding the two individual recipes I've removed dependencies from:
- libproxy: When building without gconf, -DWITH_GNOME=no has to be set.
- libsoup: When building without libgnome-keyring, --without-gnome has
to be set.
So the nomenclature would be easy for these two recipes.

As a user of OE, I see recipes inheriting gnome and gnomebase, so I'd
imagine a possible 'gnome' flag would have an effect on those recipes.

I think we have very different opinions about what GNOME is. I'd say
that hosting on GNOME's FTP server doesn't make a package a GNOME
package (e.g. gtk+, which seems to have moved to gnome.org not very long
ago. another example would be xchat vs. xchat-gnome, both of which are
hosted on gnome.org). Libxml2 is hosted on gnome.org, too, but nobody
would expect it to become unavailable if 'gnome' wasn't enabled.

What I'd expect to become disabled are GNOME executables, e.g.
gnome-panel, gnome-applets, gnome-terminal, gconfd,
gnome-keyring-daemon, etc and everything else having gnome in its name.
What would be left are libraries not having gnome in their name (because
they're generic and used by many non-GNOME-projects) which don't require
any running GNOME daemons.

I just saw that Gentoo also has a 'gnome' use flag (as well as 'X' and
'gtk'). Maybe we should look how they handle it.

> I'm starting to wonder if these shouldn't be PACKAGECONFIG options for
> the individual packages which you as a distro would then override the
> defaults for.
> 
> You could also put some of these exclusions in your distro config. You
> can check for recipes which inherit gnomebase
> (bb.data.inherits("gnomebase", d)) and then run your skip package there
> if the PN list doesn't match.

Both are options I'll consider. However, I don't think that gconf, for
example, should be enabled or disabled on a per-recipe basis.

Besides that, it's quite ugly to use oe_filter_out() etc. to remove
dependencies (e.g. on gnome-common through gnomebase). I wonder whether
there's a better way to do that.

> The main problem is I can't come up with a good flag that describes the
> package set you want to exlcude, it really is rather custom to what
> you're doing.

With OE-classic, a lot of manual patching was needed to get rid of
unwanted UI dependencies. The 'x11' flag of OE-core is definitively a
step into the right direction. But if 'x11' doesn't cover all packages
that require x11 (*), I think we should rather introduce some more
flags, instead of adding local hacks in distro.conf.

Regards,
Andreas

*) I couldn't find any report of successful use of GNOME without an
Xserver. Gtk+ even dropped DirectFB support (which wasn't enough to run
GNOME) before 3.0. So 'x11' might very well suffice, at least until
Wayland stops being a theory for OE. It would be easy to replace some
occurences of 'x11' at a later stage, after Paul's patch has been
merged, of course.

Re: [PATCH 1/5] libsoup-2.4: don't depend on libgnome-keyring unless x11 is defined

[Khem Raj]

On (22/02/12 13:56), Koen Kooi wrote:
> 
> Op 22 feb. 2012, om 12:26 heeft Andreas Oberritter het volgende geschreven:
> 
> > * Drop dependency on GNOME if x11 is disabled.
> > 
> > Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
> > ---
> > meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb |    4 ++--
> > 1 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb b/meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb
> > index 8e6ef26..861a1aa 100644
> > --- a/meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb
> > +++ b/meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb
> > @@ -6,9 +6,9 @@ LICENSE = "LGPLv2"
> > LIC_FILES_CHKSUM = "file://COPYING;md5=5f30f0716dfdd0d91eb439ebec522ec2"
> > 
> > SECTION = "x11/gnome/libs"
> > -PR = "r1"
> > +PR = "r2"
> > 
> > -DEPENDS = "glib-2.0 gnutls libxml2 libproxy sqlite3 libgnome-keyring"
> > +DEPENDS = "glib-2.0 gnutls libxml2 libproxy sqlite3 ${@base_contains('DISTRO_FEATURES', 'x11', 'libgnome-keyring', '', d)}"
> 
> that one likely needs a --disable-something to be deterministic.

may be --without-gnome or --disable-gnome-keyring ?

Re: [PATCH 1/5] libsoup-2.4: don't depend on libgnome-keyring unless x11 is defined

[Andreas Oberritter]

On 24.02.2012 09:10, Khem Raj wrote:
> On (22/02/12 13:56), Koen Kooi wrote:
>>
>> Op 22 feb. 2012, om 12:26 heeft Andreas Oberritter het volgende geschreven:
>>
>>> * Drop dependency on GNOME if x11 is disabled.
>>>
>>> Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
>>> ---
>>> meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb |    4 ++--
>>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb b/meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb
>>> index 8e6ef26..861a1aa 100644
>>> --- a/meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb
>>> +++ b/meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb
>>> @@ -6,9 +6,9 @@ LICENSE = "LGPLv2"
>>> LIC_FILES_CHKSUM = "file://COPYING;md5=5f30f0716dfdd0d91eb439ebec522ec2"
>>>
>>> SECTION = "x11/gnome/libs"
>>> -PR = "r1"
>>> +PR = "r2"
>>>
>>> -DEPENDS = "glib-2.0 gnutls libxml2 libproxy sqlite3 libgnome-keyring"
>>> +DEPENDS = "glib-2.0 gnutls libxml2 libproxy sqlite3 ${@base_contains('DISTRO_FEATURES', 'x11', 'libgnome-keyring', '', d)}"
>>
>> that one likely needs a --disable-something to be deterministic.
> 
> may be --without-gnome or --disable-gnome-keyring ?

The flag --without-gnome is right. I've updated this patch [1],
but I'm waiting before resubmitting it, because after Richard's
comments I'm unsure which distro feature should be tested or
whether PACKAGECONFIG should be used.

Regards,
Andreas

[1] http://git.openembedded.org/openembedded-core-contrib/commit/?h=obi/current&id=5c7c62268aa56a5d4d58764653ef95a9deb683ad

Re: [PATCH 1/5] libsoup-2.4: don't depend on libgnome-keyring unless x11 is defined

[Richard Purdie]

On Fri, 2012-02-24 at 14:27 +0100, Andreas Oberritter wrote:
> On 24.02.2012 09:10, Khem Raj wrote:
> > On (22/02/12 13:56), Koen Kooi wrote:
> >>
> >> Op 22 feb. 2012, om 12:26 heeft Andreas Oberritter het volgende geschreven:
> >>
> >>> * Drop dependency on GNOME if x11 is disabled.
> >>>
> >>> Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
> >>> ---
> >>> meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb |    4 ++--
> >>> 1 files changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb b/meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb
> >>> index 8e6ef26..861a1aa 100644
> >>> --- a/meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb
> >>> +++ b/meta/recipes-support/libsoup/libsoup-2.4_2.36.1.bb
> >>> @@ -6,9 +6,9 @@ LICENSE = "LGPLv2"
> >>> LIC_FILES_CHKSUM = "file://COPYING;md5=5f30f0716dfdd0d91eb439ebec522ec2"
> >>>
> >>> SECTION = "x11/gnome/libs"
> >>> -PR = "r1"
> >>> +PR = "r2"
> >>>
> >>> -DEPENDS = "glib-2.0 gnutls libxml2 libproxy sqlite3 libgnome-keyring"
> >>> +DEPENDS = "glib-2.0 gnutls libxml2 libproxy sqlite3 ${@base_contains('DISTRO_FEATURES', 'x11', 'libgnome-keyring', '', d)}"
> >>
> >> that one likely needs a --disable-something to be deterministic.
> > 
> > may be --without-gnome or --disable-gnome-keyring ?
> 
> The flag --without-gnome is right. I've updated this patch [1],
> but I'm waiting before resubmitting it, because after Richard's
> comments I'm unsure which distro feature should be tested or
> whether PACKAGECONFIG should be used.

I think the answer is we should have PACKAGECONFIG and something which
gets the defaults for that from distro features. That should actually
simplify the code a little.

I'm also wondering if a good name for the distro feature flag would be
"gnomeapi" ?

Cheers,

Richard