[PATCH] gtk+: don't provide gtk-update-icon-cache-native

[PATCH] gtk+: don't provide gtk-update-icon-cache-native

[Andreas Müller]

fixes:
| ERROR: Multiple .bb files are due to be built which each provide virtual/gtk-update-icon-cache-native
| (/home/Superandy/data/oe-core/sources/openembedded-core/meta/recipes-gnome/gtk+/gtk-update-icon-cache-native_3.4.4.bb
| virtual:native:/home/Superandy/data/oe-core/sources/openembedded-core/meta/recipes-gnome/gtk+/gtk+_2.24.15.bb).
| This usually means one provides something the other doesn't and should.

gtk-update-icon-cache-native_3.4.4 provides a version working with gtk+. This
patch was tested for gnome-icon-theme and hicolor-icon-theme by:

1. building xfce/gtk+ (gtk3-less) image
2. checking for existing icon-theme.cache in rootfs
3. running image / open menus + test applications
4. executing 'gtk-update-icon-cache-2.0 --validate <both icon-themes-dirs>'
5. executing 'gtk-update-icon-cache-2.0 -f <both icon-themes-dirs>' + exact size checking

Signed-off-by: Andreas Müller <schnitzeltony@googlemail.com>
---
 meta/recipes-gnome/gtk+/gtk+.inc        |    8 --------
 meta/recipes-gnome/gtk+/gtk+_2.24.15.bb |    5 -----
 2 files changed, 0 insertions(+), 13 deletions(-)

diff --git a/meta/recipes-gnome/gtk+/gtk+.inc b/meta/recipes-gnome/gtk+/gtk+.inc
index f05838a..84edaf3 100644
--- a/meta/recipes-gnome/gtk+/gtk+.inc
+++ b/meta/recipes-gnome/gtk+/gtk+.inc
@@ -10,8 +10,6 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=3bf50002aefd002f49e7bb854063f7e7"
 
 SECTION = "libs"
 
-PROVIDES_class-native = "virtual/gtk-update-icon-cache-native"
-
 X11DEPENDS = "virtual/libx11 libxext libxcursor libxrandr libxdamage libxrender libxcomposite"
 DEPENDS = "glib-2.0 pango atk jpeg libpng gdk-pixbuf-native docbook-utils-native \
  libgcrypt cairo gdk-pixbuf"
@@ -81,12 +79,6 @@ do_install () {
 	mv ${D}${bindir}/gtk-update-icon-cache ${D}${bindir}/gtk-update-icon-cache-2.0
 }
 
-do_install_append_class-native () {
-	# Ideally we'd use alternatives in the sysroot, but they don't work.
-	# As we know we don't have a native GTK+ 3 (yet), make a symlink instead.
-	ln -s gtk-update-icon-cache-2.0 ${D}${bindir}/gtk-update-icon-cache
-}
-
 SYSROOT_PREPROCESS_FUNCS += "gtk_sysroot_preprocess"
 
 gtk_sysroot_preprocess () {
diff --git a/meta/recipes-gnome/gtk+/gtk+_2.24.15.bb b/meta/recipes-gnome/gtk+/gtk+_2.24.15.bb
index 4e045e4..3a76393 100644
--- a/meta/recipes-gnome/gtk+/gtk+_2.24.15.bb
+++ b/meta/recipes-gnome/gtk+/gtk+_2.24.15.bb
@@ -42,11 +42,6 @@ BBCLASSEXTEND = "native"
 RRECOMMENDS_${PN}_class-native = ""
 DEPENDS_class-native = "glib-2.0-native atk-native pango-native cairo-native gdk-pixbuf-native"
 
-do_install_append_class-native () {
-	create_wrapper ${D}/${bindir}/gtk-update-icon-cache-2.0 \
-		GDK_PIXBUF_MODULE_FILE=${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/${LIBV}/loaders.cache
-}
-
 python populate_packages_prepend () {
     gtk_libdir = d.expand('${libdir}/gtk-2.0/${LIBV}')
     immodules_root = os.path.join(gtk_libdir, 'immodules')
-- 
1.7.4.4

Re: [PATCH] gtk+: don't provide gtk-update-icon-cache-native

[Burton, Ross]

On 25 March 2013 23:47, Andreas Müller <schnitzeltony@googlemail.com> wrote:
> fixes:
> | ERROR: Multiple .bb files are due to be built which each provide virtual/gtk-update-icon-cache-native
> | (/home/Superandy/data/oe-core/sources/openembedded-core/meta/recipes-gnome/gtk+/gtk-update-icon-cache-native_3.4.4.bb
> | virtual:native:/home/Superandy/data/oe-core/sources/openembedded-core/meta/recipes-gnome/gtk+/gtk+_2.24.15.bb).
> | This usually means one provides something the other doesn't and should.

NACK.

The only way this can happen is if something is depending on
gtk+-native, as everything in oe-core (should) depends on
virtual/gtk-update-icon-cache:

commit f07515096ea39e267cd3ebeea08cffbba1af07e0
Author: Ross Burton <ross.burton@intel.com>
Date:   Mon Mar 4 12:52:45 2013 +0000

    default-providers: add default virtual provider for gtk-update-icon-cache

    Use a virtual provider instead of a hard dependency so that if
gtk+-native is
    required in some configuration, this provider can be changed and then
    gtk+-native and gtk-update-icon-cache-native won't be both built
and conflict in
    the sysroot.

Presumably some application you've got is explicitly depending on
gtk+-native, probably for the icon cache handling.  It should drop
that build dependency and use the class instead.

Your fix "works" but will cause file overwrite warnings in sysroot
when you actually do want a gtk+-native, for example if you do want to
build a native gtk+ application or some reason.

Ross

Re: [PATCH] gtk+: don't provide gtk-update-icon-cache-native

[Andreas Müller]

On Tue, Mar 26, 2013 at 11:32 AM, Burton, Ross <ross.burton@intel.com> wrote:
> On 25 March 2013 23:47, Andreas Müller <schnitzeltony@googlemail.com> wrote:
>> fixes:
>> | ERROR: Multiple .bb files are due to be built which each provide virtual/gtk-update-icon-cache-native
>> | (/home/Superandy/data/oe-core/sources/openembedded-core/meta/recipes-gnome/gtk+/gtk-update-icon-cache-native_3.4.4.bb
>> | virtual:native:/home/Superandy/data/oe-core/sources/openembedded-core/meta/recipes-gnome/gtk+/gtk+_2.24.15.bb).
>> | This usually means one provides something the other doesn't and should.
>
> NACK.
>
> The only way this can happen is if something is depending on
> gtk+-native, as everything in oe-core (should) depends on
> virtual/gtk-update-icon-cache:
>
> commit f07515096ea39e267cd3ebeea08cffbba1af07e0
> Author: Ross Burton <ross.burton@intel.com>
> Date:   Mon Mar 4 12:52:45 2013 +0000
>
>     default-providers: add default virtual provider for gtk-update-icon-cache
>
>     Use a virtual provider instead of a hard dependency so that if
> gtk+-native is
>     required in some configuration, this provider can be changed and then
>     gtk+-native and gtk-update-icon-cache-native won't be both built
> and conflict in
>     the sysroot.
>
> Presumably some application you've got is explicitly depending on
> gtk+-native, probably for the icon cache handling.  It should drop
> that build dependency and use the class instead.
>
> Your fix "works" but will cause file overwrite warnings in sysroot
> when you actually do want a gtk+-native, for example if you do want to
> build a native gtk+ application or some reason.
>
> Ross
Why do we need two providers which need pinning doing exactly the same?

Andreas

Re: [PATCH] gtk+: don't provide gtk-update-icon-cache-native

[Richard Purdie]

On Tue, 2013-03-26 at 12:40 +0100, Andreas Müller wrote:
> On Tue, Mar 26, 2013 at 11:32 AM, Burton, Ross <ross.burton@intel.com> wrote:
> > On 25 March 2013 23:47, Andreas Müller <schnitzeltony@googlemail.com> wrote:
> >> fixes:
> >> | ERROR: Multiple .bb files are due to be built which each provide virtual/gtk-update-icon-cache-native
> >> | (/home/Superandy/data/oe-core/sources/openembedded-core/meta/recipes-gnome/gtk+/gtk-update-icon-cache-native_3.4.4.bb
> >> | virtual:native:/home/Superandy/data/oe-core/sources/openembedded-core/meta/recipes-gnome/gtk+/gtk+_2.24.15.bb).
> >> | This usually means one provides something the other doesn't and should.
> >
> > NACK.
> >
> > The only way this can happen is if something is depending on
> > gtk+-native, as everything in oe-core (should) depends on
> > virtual/gtk-update-icon-cache:
> >
> > commit f07515096ea39e267cd3ebeea08cffbba1af07e0
> > Author: Ross Burton <ross.burton@intel.com>
> > Date:   Mon Mar 4 12:52:45 2013 +0000
> >
> >     default-providers: add default virtual provider for gtk-update-icon-cache
> >
> >     Use a virtual provider instead of a hard dependency so that if
> > gtk+-native is
> >     required in some configuration, this provider can be changed and then
> >     gtk+-native and gtk-update-icon-cache-native won't be both built
> > and conflict in
> >     the sysroot.
> >
> > Presumably some application you've got is explicitly depending on
> > gtk+-native, probably for the icon cache handling.  It should drop
> > that build dependency and use the class instead.
> >
> > Your fix "works" but will cause file overwrite warnings in sysroot
> > when you actually do want a gtk+-native, for example if you do want to
> > build a native gtk+ application or some reason.
> >
> > Ross
> Why do we need two providers which need pinning doing exactly the same?

I'd love to remove gtk+-native.

The icon-cache-native gives about a 5% build speedup as it has a lot
less dependencies than gtk+-native so it is a good thing. We could fix
things to coexist however unless there is a good reason to keep gtk
+-native around, we should switch things over. Things were therefore
left like this to provide gentle pressure to layers that are still using
gtk+-native.

If there are valid cases where gtk+-native is still necessary we can
revisit this but we're not aware of any right now.

Cheers,

Richard

Re: [PATCH] gtk+: don't provide gtk-update-icon-cache-native

[Andreas Müller]

On Wed, Mar 27, 2013 at 8:56 AM, Andreas Müller
<schnitzeltony@googlemail.com> wrote:
> On Wed, Mar 27, 2013 at 12:29 AM, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> On Tue, 2013-03-26 at 15:28 +0100, Andreas Müller wrote:
>>> On Tue, Mar 26, 2013 at 12:48 PM, Richard Purdie
>>> <richard.purdie@linuxfoundation.org> wrote:
>>> > On Tue, 2013-03-26 at 12:40 +0100, Andreas Müller wrote:
>>> >> On Tue, Mar 26, 2013 at 11:32 AM, Burton, Ross <ross.burton@intel.com> wrote:
>>> >> > On 25 March 2013 23:47, Andreas Müller <schnitzeltony@googlemail.com> wrote:
>>> >> >> fixes:
>>> >> >> | ERROR: Multiple .bb files are due to be built which each provide virtual/gtk-update-icon-cache-native
>>> >> >> | (/home/Superandy/data/oe-core/sources/openembedded-core/meta/recipes-gnome/gtk+/gtk-update-icon-cache-native_3.4.4.bb
>>> >> >> | virtual:native:/home/Superandy/data/oe-core/sources/openembedded-core/meta/recipes-gnome/gtk+/gtk+_2.24.15.bb).
>>> >> >> | This usually means one provides something the other doesn't and should.
>>> >> >
>>> >> > NACK.
>>> >> >
>>> >> > The only way this can happen is if something is depending on
>>> >> > gtk+-native, as everything in oe-core (should) depends on
>>> >> > virtual/gtk-update-icon-cache:
>>> >> >
>>> >> > commit f07515096ea39e267cd3ebeea08cffbba1af07e0
>>> >> > Author: Ross Burton <ross.burton@intel.com>
>>> >> > Date:   Mon Mar 4 12:52:45 2013 +0000
>>> >> >
>>> >> >     default-providers: add default virtual provider for gtk-update-icon-cache
>>> >> >
>>> >> >     Use a virtual provider instead of a hard dependency so that if
>>> >> > gtk+-native is
>>> >> >     required in some configuration, this provider can be changed and then
>>> >> >     gtk+-native and gtk-update-icon-cache-native won't be both built
>>> >> > and conflict in
>>> >> >     the sysroot.
>>> >> >
>>> >> > Presumably some application you've got is explicitly depending on
>>> >> > gtk+-native, probably for the icon cache handling.  It should drop
>>> >> > that build dependency and use the class instead.
>>> >> >
>>> >> > Your fix "works" but will cause file overwrite warnings in sysroot
>>> >> > when you actually do want a gtk+-native, for example if you do want to
>>> >> > build a native gtk+ application or some reason.
>>> >> >
>>> >> > Ross
>>> >> Why do we need two providers which need pinning doing exactly the same?
>>> >
>>> > I'd love to remove gtk+-native.
>>> >
>>> > The icon-cache-native gives about a 5% build speedup as it has a lot
>>> > less dependencies than gtk+-native so it is a good thing. We could fix
>>> > things to coexist however unless there is a good reason to keep gtk
>>> > +-native around, we should switch things over. Things were therefore
>>> > left like this to provide gentle pressure to layers that are still using
>>> > gtk+-native.
>>> >
>>> > If there are valid cases where gtk+-native is still necessary we can
>>> > revisit this but we're not aware of any right now.
>>> >
>>> > Cheers,
>>> >
>>> > Richard
>>> The patch I sent was the attempt to take the first step for
>>> gtk-update-icon-cache-native.
>>> What I see from the tests is that there is no fallout using build time
>>> optimized gtk-update-icon-cache-native based on gtk3. There is no need
>>> for alternate providers here. OK the patch didn't replace
>>> virtual/gtk-update-icon-cache-native by gtk-update-icon-cache-native -
>>> but I could send V2 if the direction is agreed.
>>
>> So to be clear you're saying we don't need gtk+-native for any user
>> you're aware of? Can we remove the BBCLASSEXTEND for native in that
>> case?
>>
>>> If I remember correct there are other gtk-native parts used by the
>>> offline image creation. I don't know what we can replace by optimized
>>> native recipes (based on gtk3).
>>
>> I don't think any of the offline image pieces are using gtk+-native any
>> more...
>>
>> Cheers,
>>
>> Richard
> I will repeat my tests with complete remove of gtk+- native extension.
> If it works I will send a patch - otherwise drop a note.
>
In my environment I found the following references on gtk+-native:

meta-browser: chromium
openembedded-core: packagegroup-toolset-native
openembedded-core: sstate.bbclass
openembedded-core: seperatebuilddir.inc

I have no idea what the oe-core part is for. Since chromium never
built for me: Could the meta-browser friends check which part of
gtk+-native is required - or if replacing gtk+-native by
gtk-update-icon-cache-native is enough?

Andreas

Re: [PATCH] gtk+: don't provide gtk-update-icon-cache-native

[Burton, Ross]

Hi Andreas,

On 27 March 2013 08:27, Andreas Müller <schnitzeltony@googlemail.com> wrote:
> meta-browser: chromium

The latest commit to the Chromium 24 recipe changes gtk+-native to
gtk+, so it appears that any gtk+-native references you're seeing are
bad and the same fix should be applied to the other versions.

> openembedded-core: packagegroup-toolset-native

This is a packagegroup that builds ~all of the native packages.

> openembedded-core: sstate.bbclass

    def isPostInstDep(x):
        if x in ["qemu-native", "gdk-pixbuf-native", "gtk+-native",
"qemuwrapper-cross", "depmodwrapper-cross",
"systemd-systemctl-native", "gtk-update-icon-cache-native"]:
            return True
        return False

Some sstate black magic.

> openembedded-core: seperatebuilddir.inc

Just a variable saying it can be built out of tree.

packagegroup-toolset-native is the only place that actually uses
gtk+-native, so anyone actually using that for whatever purpose will
need to set the preferred provider.

Ross

Re: [PATCH] gtk+: don't provide gtk-update-icon-cache-native

[Richard Purdie]

On Wed, 2013-03-27 at 10:23 +0000, Burton, Ross wrote:
> Hi Andreas,
> 
> On 27 March 2013 08:27, Andreas Müller <schnitzeltony@googlemail.com> wrote:
> > meta-browser: chromium
> 
> The latest commit to the Chromium 24 recipe changes gtk+-native to
> gtk+, so it appears that any gtk+-native references you're seeing are
> bad and the same fix should be applied to the other versions.
> 
> > openembedded-core: packagegroup-toolset-native
> 
> This is a packagegroup that builds ~all of the native packages.
> 
> > openembedded-core: sstate.bbclass
> 
>     def isPostInstDep(x):
>         if x in ["qemu-native", "gdk-pixbuf-native", "gtk+-native",
> "qemuwrapper-cross", "depmodwrapper-cross",
> "systemd-systemctl-native", "gtk-update-icon-cache-native"]:
>             return True
>         return False
> 
> Some sstate black magic.

That can just be removed if we don't use gtk+-native in any postinsts
which I don't believe we do now...

> > openembedded-core: seperatebuilddir.inc
> 
> Just a variable saying it can be built out of tree.

Right, that can also just be dropped.

> packagegroup-toolset-native is the only place that actually uses
> gtk+-native, so anyone actually using that for whatever purpose will
> need to set the preferred provider.

This can also just get dropped, it was only there to allow building the
collection of native recipes.

So as far as I'm concerned all these references can just be removed.

Cheers,

Richard