hi, woeusb depends on wxGTK::3-0-gtk3 but also works fine with wxGTK::3.0 without gtk3 as well. I tested woeusb-3.1.5, but I'm guessing the same holds for 3.2.12 as well... cheers
wxGTK applications are meant to use only 3.0-gtk3 when they work fine with gtk3. This is not a choice that can be provided by the same ebuild, and it is not something that maintainers should provide multiple revisions of either. gtk2 itself has been dead for years, and should not be used when it works with gtk3. Sorry. Leaving any final decision to package maintainer; just throwing in my wxGTK de jure maintainer cents
(In reply to Mart Raudsepp from comment #1) > wxGTK applications are meant to use only 3.0-gtk3 when they work fine with > gtk3. This is not a choice that can be provided by the same ebuild my ebuild-foo might be a bit rusty, just RDEPENDing on ">=x11-libs/wxGTK-3.0" should make the ebuild compatible with whatever choice the user takes, no? And Gentoo _is_ about choice IIRC :) In particular, I'm not going to compile a huge library just for a small tool that I'll use for 10 minutes, just because someone somewhere decided for me that I should not use gtk2. That being said, I may be alone in this and I'm happy with my custom ebuild, I just thought it was a restriction where none is necessary, which constitutes a bug in my world :)
No, change WX_GTK_VER="3.0-gtk3" to WX_GTK_VER="3.0" instead then. The depend change will not make it compatible with both, WX_GTK_VER chooses which one. This is wxwidgets.eclass logic. It is not valid to depend on both, as the package manager doesn't know which and may allow to depclean the wrong thing. It's also bad for other reasons. You can choose to maintain your own version or maybe Pacho as actual maintainer of woeusb feels different. I suppose you already have gtk2 wxGTK due to wxpython or something? Otherwise most things are already using gtk3 and if not, maybe that's the solution instead - have that use gtk3 too; not force woeusb to ancient gtk. Unfortunately wxpython bits need some tending to, to make that use gtk3 always and I haven't had the time compared to other priorities (which is why I referred to myself as wxWidgets de jure maintainer, hinting that I'm not really de facto maintainer - no-one really is :( )
ah interesting, thanks for the hint :) % equery d wxGTK * These packages depend on wxGTK: app-arch/p7zip-16.02-r4 (wxwidgets ? x11-libs/wxGTK:3.0[X]) app-crypt/veracrypt-1.23 (x11-libs/wxGTK:3.0[X?]) media-sound/audacity-2.2.2 (x11-libs/wxGTK:3.0[X]) media-video/mediainfo-18.08.1 (wxwidgets ? x11-libs/wxGTK:3.0[X]) sci-visualization/gnuplot-5.2.2 (wxwidgets ? x11-libs/wxGTK:3.0[X]) in fact, the main programs I depend on that need gtk2-wxGTK are veracrypt, gnuplot and audacity (at least veracrypt explicitly states in their dependencies that they want the gtk2 version of wxGTK) But IMHO, what you're describing seems like a design flaw in the wx eclass then, for not allowing us to express that applications work with both gtk2 and gtk3 versions of wxGTK...
(In reply to igel from comment #4) > But IMHO, what you're describing seems like a design flaw in the wx eclass > then, for not allowing us to express that applications work with both gtk2 > and gtk3 versions of wxGTK... No, that would be the design flaw and probably also a QA violation. A nightmare to maintain for sure. Sure, it's nice for a single package, but we have a whole distro to maintain. On top of that, also consider that wxWidgets apps could be writing their own extra code for wxGTK to get better results for something, and then you need any supporting gtk ecosystem libraries to use the correct thing too.
I depended on gtk3 intentionally because gtk2 is in maintainance mode for years
