kdegraphics (not meta) has an option to compile without imlib support. kdegraphics-meta does not have this USE-flag. As a result, there is no way to have "emerge kde-meta" not pull in gtk+-1*. Not exactly critical, but fairly annoying anyway. Reproducible: Always Steps to Reproduce: 1.emerge -vp kde-meta 2. 3. Actual Results: gtk+-1.2.10-r11 is merged Expected Results: gtk+-1.2.10-r11 should not be merged The imlib dependency come from kuickshow
kuickshow is in kdegraphics-meta -> kuickshow needs imlib -> kdegraphics-meta needs imlib -> invalid bug. Don
kuickshow is in kdegraphics-meta -> kuickshow needs imlib -> kdegraphics-meta needs imlib -> invalid bug. Don´t use -meta if you dislike it.
I realize what you are saying, but I am only requesting functionality that is already in the "normal" kdegraphics module. There are already options to disable kamera, kooka and kpovmodeler. I use the -meta packages because I want all (rather, the large majority) of the packages that kde provides and the -meta packages provide some benefits that I believe are worth it. In addition, in the future, only kde-meta will be provided and not monolithic "kde" so it is good to get used to working with the new system. I also dont feel like manually emerging 300 odd packages. It may have been practical with the old monolithic system, but it just doesnt cut it with all the individual packages.
>I realize what you are saying, but I am only requesting functionality that is already in the "normal" kdegraphics module. The difference is that the meta ebuilds are meant as a simplification for those who want the whole kde.org package. If you don't, then don't use the meta ebuild. >As a result, there is no way to have "emerge kde-meta" not pull in gtk+-1*. That's not quite true. It's possible to install imlib without the gtk dependency. To do this all you have to do is to copy the ebuild in your overlay and add sed -i -e 's:GDK_IMLIB="gdk_imlib utils":GDK_IMLIB="":' configure || die "sed failed" at the end of src_unpack(). As you can read in https://bugs.gentoo.org/show_bug.cgi?id=40453#c24 the gnome herd refuses to add this as option to the imlib ebuild.
Created attachment 58897 [details] new ebuild Ok, I'll try one more time to convince you guys... Though the solution you propose is probably better and I'll probably end up using it eventually, I don't think its a good solution for the distribution. And I think that "emerge -vp kde-meta" will be a common task once it goes stable, and I also think the desire of kde-users issuing that command to not pull in gtk+-1* will be pretty great. And I think that there should be someway outside editing an ebuild to grant that desire (while still using the -meta ebuild). I honestly dont understand the resistance to this change. Its literally two lines difference; there are already 3 similar useflags in the exact same package that have the exact same function; and this useflag was in the kdegraphics ebuild (which kdegraphics-meta will eventually replace).
*** Bug 91989 has been marked as a duplicate of this bug. ***
The case against the imlib flag as I see it is roughly like this: The imlib use flag is about optional imlib support. There's no optional support issue here. kuickshow has a hard dep on imlib, and kdegraphics-meta is defined as 'the -meta package of all kdegraphics apps', so it includes kuickshow. There's no optional support of imlib involved anywhere. Contrast this with the other USE flags appearing in kdegraphics-meta: e.g. scanner means 'do whatever is necessary to support scanners'. Ditto for gphoto2. And povray is a local use flag which only exists because povray is a heavy dep and very few users need it, so off by default is sensible. This reasoning doesn't apply to kuickshow/imlib. (Not to say that every single use flag in a -meta package fully follows this logic...) This would mean the imlib flag shouldn't exist in kdegraphics either. It was originally added due to a request, bug #62284.
