On Tue, 2013-03-26 at 12:40 +0100, Andreas Müller wrote: > On Tue, Mar 26, 2013 at 11:32 AM, Burton, Ross <[email protected]> wrote: > > On 25 March 2013 23:47, Andreas Müller <[email protected]> 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 <[email protected]> > > 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 _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
