I do not have KDE installed on my system, but I had "kde" in my USE flags. Maybe I was going to get around to installing it, or something. Or maybe I just never turned it off. However, I installed gentoo-artwork, with the "kde" USE flag on. Here is an excerpt from the ebuild: DEPEND="" ... if [ `use kde` ] ; then # a Gentoo colour scheme for KDE insinto ${KDEDIR}/share/apps/kdisplay/color-schemes doins ${S}/misc/Gentoo.kcsrc fi Now, if KDE is not installed, then the KDEDIR environment variable is not set. As a result, I found a directory in my root called "/share", which had a KDE colour scheme somewhere underneath it. Certainly undesirable. I unmerged it: <<< obj /share/apps/kdisplay/color-schemes/Gentoo.kcsrc <<< dir /share/apps/kdisplay/color-schemes <<< dir /share/apps/kdisplay <<< dir /share/apps <<< dir /share This is not the only package with the problem. A quick grep found me another one: app-misc/lcd4linux DEPEND="png? ( media-libs/libpng sys-libs/zlib media-libs/libgd )" (Note that it doesn't require that KDE is installed.) if [ `use kde` ] ; then insinto /etc/lcd4linux insopts -o root -g root -m 0600 doins lcd4kde.conf insinto ${KDEDIR}/share/applnk/apps/System doins lcd4linux.kdelnk insinto ${KDEDIR}/share/icons doins lcd4linux.xpm touch ${D}/etc/lcd4linux/lcd4X11.conf fi Same story. Maybe a check should be made to see whether KDE is installed, not just whether the KDE USE flag is being used?
another good example of how i wish the kde/qt eclasses provided an 'easy' interface for all the other packages in portage
Looks like the older versions had kdebase as a dep, but this new one doesn't. Anyway, last version was by Troy so I'll let him think about it :)
In any case packages should install all their kde bindings into /usr/share/... etc, not in KDEDIR as they are in general independent of the kde version used. This way they work with all kde versions installed and will continue to work with an update.
tad is not an active developer.
This stuff goes in /usr _not_ $KDEDIR. desktop-misc herd: rss-glx, gentoo-artwork, redhat-artwork, mandrake-artwork, lcd4linux net-im herd: amsn, ymessenger java herd: poseidonCE, netbeans, sun-jre-bin
I should ave fixed all cases I could find throughout the tree, so the situation now is much cleaner: Hopefully all ebuilds using KDEDIR make sure that it is set (by using the kde eclasses and functions). Only in rare cases an ebuild puts something in KDEDIR. At this point it should be safe to remove KDEDIR from the environment, which I can do in a few days...
see previous comment.
