These packages make use of gtk3 useflag which indicates that there are issues of migration to gtk+:3. Gtk3 and similar useflags should be avoided. Adding to tracker. Please have a look.
splitting from sabayon could solve this :/
I'm having a hard time understanding this bug. What's wrong with having the two flags with the following behavior: 1) USE="gtk -gtk3" <- link against gtk+:2 2) USE="-gtk gtk3" <- link against gtk+:3 3) USE="gtk gtk3" <- link against gtk+:3 Furthermore many of these dependencies use-dep on either gtk or gtk3. It looks like it would be a mess to disentangle for little profit. If anyone feel strongly about this issue, please reopen the bug and help me understand why this is important.
the reasons are explained in the tracker Basically it causes confusion for the user and is in many cases unnecessary. "gtk" useflag was not meant to be slot-specific in the first place, but the gtk useflag in your ebuild IS slot specific which collides with the generic meaning of that useflag which is "Adds support for x11-libs/gtk+" thus indicating that this is the only thing to get gtk+ support for apps. Gnome herd also advises to only support the latest gtk+ slot if possible (unless that is more buggy or has less features). I do not see any complication in this ebuild that would prevent dropping gtk+:2 dep entirely and converting "gtk3" useflag to "gtk". Also mind that gtk+:3 is already stable and that people would have to do "-gtk" for your ebuild to disable the gtk+:2 specific bits which does not make sense.
(In reply to Julian Ospald (hasufell) from comment #3) > the reasons are explained in the tracker > > Basically it causes confusion for the user and is in many cases unnecessary. > "gtk" useflag was not meant to be slot-specific in the first place, but the > gtk useflag in your ebuild IS slot specific which collides with the generic > meaning of that useflag which is "Adds support for x11-libs/gtk+" thus > indicating that this is the only thing to get gtk+ support for apps. > Gnome herd also advises to only support the latest gtk+ slot if possible > (unless that is more buggy or has less features). I do not see any > complication in this ebuild that would prevent dropping gtk+:2 dep entirely > and converting "gtk3" useflag to "gtk". > > Also mind that gtk+:3 is already stable and that people would have to do > "-gtk" for your ebuild to disable the gtk+:2 specific bits which does not > make sense. So what's the plan, drop gtk3 and just use gtk? This would break reverse dependencies which use-dep on avahi with gtk3. Also, users don't have to do -gtk. They only have to do gtk3 which overrides the gtk flag.
(In reply to Anthony Basile from comment #4) > > So what's the plan, drop gtk3 and just use gtk? This would break reverse > dependencies which use-dep on avahi with gtk3. Yes, reverse deps can be fixed. > > Also, users don't have to do -gtk. They only have to do gtk3 which > overrides the gtk flag. Even more confusing.
(In reply to Julian Ospald (hasufell) from comment #5) > Even more confusing. besides, if they enable both gtk and gtk3, then they get both dependencies without a reason
