[OE-core] [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 at intel.com> wrote:
> > On 25 March 2013 23:47, Andreas Müller <schnitzeltony at 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 at 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