After removing gtk+:3: !!! existing preserved libs: >>> package: x11-libs/gtk+-3.0.10 * - /usr/lib64/libgdk-3.so * - /usr/lib64/libgdk-3.so.0 * - /usr/lib64/libgdk-3.so.0.0.10 * used by /usr/bin/rsvg-view-3 (gnome-base/librsvg-2.34.0) * - /usr/lib64/libgtk-3.so * - /usr/lib64/libgtk-3.so.0 * - /usr/lib64/libgtk-3.so.0.0.10 * used by /usr/bin/rsvg-view-3 (gnome-base/librsvg-2.34.0)
I would report this to upstream also
Feel free to :D.
I am unsure about if we should try to have a "--enable/disable-gtk{2,3}" or simply build both :-/ (looks like there are no many packages with a "gtk3" USE flag) the offending code looks to be at: dnl =========================================================================== dnl GTK theme engine dnl =========================================================================== AC_MSG_CHECKING([whether to build the GTK+ theme engine]) AC_ARG_ENABLE([gtk-theme], [AS_HELP_STRING([--disable-gtk-theme],[Disable a RSVG based GTK+ theme engine (default=yes)])], [],[enable_gtk_theme=yes]) AC_MSG_RESULT([$enable_gtk_theme]) have_gtk_2=no have_gtk_3=no GTK2_BINARY_VERSION= GTK3_BINARY_VERSION= if test "x$enable_gtk_theme" = "xyes" -o "x$enable_pixbuf_loader" = "xyes"; then PKG_CHECK_MODULES([GTK2],[gtk+-2.0 >= $GTK2_REQUIRED],[have_gtk_2=yes],[have_gtk_2=no]) PKG_CHECK_MODULES([GTK3],[gtk+-3.0 >= $GTK3_REQUIRED],[have_gtk_3=yes],[have_gtk_3=no]) if test "$have_gtk_2" = "yes"; then GTK2_BINARY_VERSION="`$PKG_CONFIG --variable=gtk_binary_version gtk+-2.0`" fi if test "$have_gtk_3" = "yes"; then GTK3_BINARY_VERSION="`$PKG_CONFIG --variable=gtk_binary_version gtk+-3.0`" fi fi AC_SUBST([GTK2_BINARY_VERSION]) AC_SUBST([GTK3_BINARY_VERSION]) AM_CONDITIONAL([ENABLE_GTK_ENGINE],[test "$enable_gtk_theme" = "yes"]) AM_CONDITIONAL([HAVE_GTK_2],[test "$have_gtk_2" = "yes"]) AM_CONDITIONAL([HAVE_GTK_3],[test "$have_gtk_3" = "yes"])
Yeah I told nirbheek this caused automagic dependency when he commited this ebuid by mistake. We should make we have the loader for gtk3 when gtk3 is installed and same for gtk2. * Slotting is possible, maybe not the best * Could have use flag is slotting doesn't work or isn't approved * Forcing the build of both is not ideal and I wouldn't be in favor of it at all
(In reply to comment #4) > Yeah I told nirbheek this caused automagic dependency when he commited this > ebuid by mistake. Should librsvg-2.34.0 be skipped from stabilization in bug 369909 due this problem then? (even gtk+-3 not being stable yet...)
That would be preferable to avoid dealing with this in stable for now.
Created attachment 277757 [details, diff] 1.patch This patch looks to fix this for me, but we need to decide how to handle this now (slotting -> in that case how to handle with colliding files), or a gtk3 USE flag...
In the USE flag case: that patch would be fine if it allowed both to be compiled at the same time :p if you don't want to change the patch though, maybe having the ebuild do out-of-tree build like I did for gtk-vnc would do it for us. In the slotting case: that patch is fine, we just do a r1 and block older release in slotted revisions just like I did for libwpd and libwps (iirc)
Maybe both could be support with --with-gtk=all, as most setups will have gtk+2 and 3 at the same time in the near future
Created attachment 277877 [details, diff] 1.patch Updated patch with "all" option, the configure invocation would be as follows: pkg_setup() { # croco is forced on to respect SVG specification G2CONF="${G2CONF} --disable-static $(use_enable tools) $(use_enable gtk gtk-theme) --with-croco --enable-pixbuf-loader" use gtk && ! use gtk3 && G2CONF+=" --with-gtk=2.0" use gtk && use gtk3 && G2CONF+=" --with-gtk=all" ! use gtk && use gtk3 && G2CONF+=" --with-gtk=3.0 --enable-gtk-theme" DOCS="AUTHORS ChangeLog README NEWS TODO" } But please review this as I am also thinking in other things related with real life now and I am not 100% sure this is the simplest way to handle this
I am also unsure about: pkg_postinst() { gdk-pixbuf-query-loaders > "${EROOT}/usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache" } pkg_postrm() { gdk-pixbuf-query-loaders > "${EROOT}/usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache" } As it would probably require some addition for gtk3 :S
so you want USE flag solution ?
(In reply to comment #12) > so you want USE flag solution ? Yes, I would prefer it as the difference between building it with gtk3 support or not is only for gtk-theme, the rest of files are common
As I have seen in other third party projects, "both" is used instead of "all" for building with support for both gtk+ versions, maybe we could use that one (and apply the patch for releasing a librsvg for gtk+2 to go to stable and another one with support for all combinations for "testing")
+ 26 Jun 2011; Pacho Ramos <pacho@gentoo.org> -librsvg-2.26.3.ebuild, + librsvg-2.34.0.ebuild, +librsvg-2.34.0-r1.ebuild, + +files/librsvg-2.34.0-automagic-gtk.patch: + Fix automagic gtk+ dependency (bug #371290 by Michał Górny), remove old. + Will keep this opened as probably Gilles wants to handle this in a bit different way (but this allows us to unblock bug 369909)
(In reply to comment #11) > I am also unsure about: > > pkg_postinst() { > gdk-pixbuf-query-loaders > > "${EROOT}/usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache" > } > > pkg_postrm() { > gdk-pixbuf-query-loaders > > "${EROOT}/usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache" > } > > > As it would probably require some addition for gtk3 :S There is only one gdk-pixbuf, and both gtk2 and gtk3 link against it (in fact, gtk3 is the reason it was split from gtk2).
Are we ok with this solution then?
Will close this in a week if nobody disagrees
(In reply to comment #18) > Will close this in a week if nobody disagrees
