This ebuild popped up in x86-testing and, if not modified by hand, forces me to install gtk-1.2 and glib-1.2, which is completely unnecessary. I suggest checking for the "gtk/gtk2"-USE-flag, as it is done by redhat-artwork or gftp for example, and will be needed for upcoming freeciv. Please integrate these checks. :) Reproducible: Always Steps to Reproduce: 1. 2. 3.
the problem here is that -gtk +gtk2 is not a valid combination of useflags according to the description. we certainly don't want to encourage people doing that because it leads to problems with other packages. however, we did consider your case where you don't have gtk+1 and don't want it to install. The eclass has some logic that should not force you to install gtk+-1 unless you install a engine that only has a gtk+-1 version. i'll look into why that is happening.
suntory x11-themes # etcat versions x11-libs/gtk+ [ Results for search key : x11-libs/gtk+ ] [ Applications found : 1 ] * x11-libs/gtk+ : [ ] x11-libs/gtk+-1.2.10-r9 (1) [ ] x11-libs/gtk+-1.2.10-r10 (1) [ ] x11-libs/gtk+-2.2.1 (2) [ ~I] x11-libs/gtk+-2.2.1-r1 (2) [ ~ ] x11-libs/gtk+-2.2.2-r1 (2) suntory x11-themes # emerge -p gtk-engines These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild N ] x11-themes/gtk-engines-2.2.0 doesn't do it for me ..
Sorry, been rebuilding my whole system after 1.2 -> 1.4 upgrade failed. And I ran into the same problem again: root@giant root # etcat versions x11-libs/gtk+ [ Results for search key : x11-libs/gtk+ ] [ Applications found : 1 ] * x11-libs/gtk+ : [ ] x11-libs/gtk+-1.2.10-r9 (1) [ ] x11-libs/gtk+-1.2.10-r10 (1) [ ] x11-libs/gtk+-2.2.1 (2) [ ~ ] x11-libs/gtk+-2.2.1-r1 (2) [ ~I] x11-libs/gtk+-2.2.2-r1 (2) root@giant root # emerge -pv gtk-engines These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild U ] x11-libs/gtk+-1.2.10-r10 [2.2.2-r1] +nls [ebuild N ] x11-themes/gtk-engines-2.2.0 I tried masking gnome-themes-2.2.1-r1 which triggers gtk-engines, but therefor I got a dependency on gtk-enignes-thinice-2.0.2-r1, which again triggers gtk+-1.2 for me. Looking into the ebuilds for gnome-themes-2.2.2-r1 and gtk-engines-thinice-2.0.2-r1 both have a new feature in their r1-release: GTK1-packages. But without gtk use-flag,a nd the magic obviously fails for me. Another thing: Why should -gtk and +gtk2 be an invalid combination? I like gtk2-software, but there are so many apps offering an optional gtk-1.2-frontend which I don't want to use, so it's a perfect combination for me at least. :)
why USE="-gtk gtk2" is invalid: The gtk2 useflag is a preference setting, stating that if a software gives both a gtk and an optional, updated, almost-working gtk2 interface (mozilla, gftp, amongst others) then it should build the gtk2 interface instead of the gtk interface. This is a transition flag, for when packages have -both- interfaces, but its a "choose one over the other" situation. Think of the test such as this: if USE=gtk then if USE="gtk2" build gtk2 interface else build gtk interface end -gtk disables -all- gtk based interfaces, wether 1.2 or 2.0 version. gtk2 is the preference flag. A look inside the documentation will aslso show you this: grep gtk2 /usr/portage/profiles/use.desc: gtk2 - use gtk+-2.0.0 over gtk+-1.2 in cases where a program supports both. beware that gtk+-2 support can be bad.
Ok, I understand the motivation behind this design: you want to avoid a gtk3-flag and so on, just like qt succeeds to do. But yet I don't think it's a that good decision. Someone who's using gtk2 doesn't necessarily want all the gtk1-libs, which you will inevitably get with a "gtk"-flag due to many packages (mplayer, xine... if I remeber correctly). The same goes for the "gnome"-flag. If I don't set it, I won#t get gnome2-support in dia-0.91, iif I set it, it will install gtkmm-1.2 for a GUI in cdrdao... Dependent use-flags aren't a good idea imho, but my portage-modification-script is 2 pages long anyway, so I don't consider it really critical.
i think the problem stems from the metadata cache regeneration (on the server side) assuming that you have +gtk -gtk2 (which is the gentoo default). if you do: touch /usr/portage/x11-themes/gtk-engines/gtk-engines-2.2.0.ebuild and then emerge, it should force it to regenerate the cache for that ebuild using your setup. i'll have to ask carpaski about the best way to go about fixing the behaviour of this eclass.
Wow, that was it. After the touch-command it won't want to install gtk-1.2 anymore, no matter what USE-flags I set. I assume it looks whether gtk1 is installed or not and decides which engines to install upon that, and not on the use-flags? I definitely like it that way. :)
carpaski have a look please ?
Summarizing: This affects the two ebuilds "gtk-engines-2.2.0" and "gtk-engines-thinice-2.0.2-r1" in the same way. Emerging them after a sync wants to install gtk+-1.2, after "touching" them, they don't want to anymore, which is what the "magis" is supposed to do, as I have no gtk1-stuff at all. Is there any sense working on gtk+-1 backwards-compatibility now, that gtk2 is more and more spread? Would have made sense a year ago, but the gtk1-sfeatures are new in these ebuilds.
the problem is the portage cache, not what we do in the eclass/ebuilds. And yes there is sense in having working gtk1 support, there are people still using only that.
since i can't pinpoint what exactly went wrong here and reproduce it i'm closing this one. This is not a problem with the ebuilds we provide, but possibly some issue with portage cache.
