I recently updated my system to the Gnome 2.2 series, which meant that a number of libraries were moved around. This necessitated recompilation of a number of applications, large and small. (Not sure if everyone will need to do this later on, I've been tracking most of the 2.1.x development outside of portage). What must be said, though, is that the most annoying of the bunch was the gtk-engines series. Once I noticed the big package's removal, I simply used gtk-themes to update it, as I saw mentioned in bug 8201. Anyway, to make a long story short when I went to rebuild them, 'emerge /usr/portage/x11-themes/gtk-engines*/g*.ebuild' (after deleting the ebuilds for irrelevent versions) was pretty darn inconvenient when contrasted with a meta package which perhaps depends on the latest version of each engine or instead installs the whole gtk-engines package in slot-2 while you can continue to maintain separate ebuilds for the gtk-1 versions under the various gtk-engines-whatever tags.
I'm afraid I don't understand you very well. You don't need to 'emerge /usr/portage/x11-themes/gtk-engines*/g*.ebuild', nor "delete the ebuilds for irrelevent versions". If you read the comments on bug #8201, you can find the following: There is a convenient package which install all the proper engines you might want: gtk-themes. If you want Gtk 2 themes you can just 'emerge gtk-themes'. However, if you want Gtk 1 themes, you can 'emerge =gtk-themes-1.0*' As far as I can tell, once you upgraded to Gnome 2, all you had to do to is ``emerge gtk-themes'' and that's all there is to it. gtk-themes _is_ the meta-package in this case. Did I misunderstand you?
You've misunderstood me somewhat. I already had most of the theme engines installed. I needed (in order to eliminate annoying console error messages) to recompile several of them, and I figured I might as well do the whole batch. As the engines were already installed, remerging gtk-themes without the --emptytree option would do nothing for me. Using the --emptytree option, on the other hand, would rebuild dozens of packages needlessly. What I'm really protesting is that the gtk-engines package (distributed by GNOME) has been broken up into about ten separate ebuilds (which is fine as an option, I guess, for those people who really feel a need to save 400 kb of disk space) and that the one big package which handled them all is gone. If you want/need to remerge them (same versions as are already installed), this means ten packages must be rebuilt rather than one.
the last gtk+ ebuild containts a simple line at then end to rebuild your installed theme engines. btw leonardp, i dont have much dealings with engines, but shouldnt they be updated sinec the new gtk-engines pack is out and i see some themes are b0rked here and i suspect it has todo with engines being too old ? reporter : in time it doesnt matter if you compile one big pack or several smaller ones, so i don't really see that point. And i don't think its broken up for diskspace, but for conformation between the engines.
foser: So it does. I must have missed that thanks to that little problem called 'merging multiple packages at a time' (And yes, I know of and can't be bothered to use the workaround mentioned in aone of the newsletters.) The dig about disk space was more of a joke than anything - I don't think it was necessary to split them out in the first place. Either way, feel free to close this bug unless you want it open as an 'update gtk-engines' reminder.
im closing this, i don't really think its a good idea to have a gtk-engines package while there are several gtk-engines-* packages around. Too confusing, packages depending on gtk-engines should just depend on the seperate engines contained in the pack like the newest gnome-themes ebuild.
