startkde contains references to lnusertemp, and $ kde4-config --path exe --locate lnusertemp /usr/bin/lnusertemp $ rpm -q -f /usr/bin/lnusertemp kdelibs3-3.5.9-15.fc9.x86_64 I moved that out of the way, and the kde4-config call finds nothing $ mv /usr/bin/lnusertemp /usr/bin/lnusertemp.kde3 $ kde4-config --path exe --locate lnusertemp <blank> Net result is that kde4 session fails to start if kdelibs3 isn't installed.
fwiw, $ kde4-config --path exe /home/rdieter1/.kde/libexec/kde4/:/home/rdieter1/.kde/bin/:/usr/bin/ no /usr/libexec ?
With kdelibs-4.0.5-2.fc9, I get: /home/kevin/.kde/libexec/kde4/:/home/kevin/.kde/bin/:/usr/bin/:/usr/libexec/kde4/ Likewise kdelibs4-4.0.5-2.fc8. So this sounds like a regression in our KDE 4.1 packages. (Rex is using 4.0.83.) Still the order is bad, /usr/libexec/kde4 should come first, this sounds like fallout from the kstandarddirs patch.
The ordering issue on F9 can probably be fixed by changing: if (strcmp("config", type)) to: if (strcmp("config", type) && strcmp("exe", type)) and: if (!strcmp("config", type)) to: if (!strcmp("config", type) || !strcmp("exe", type)) in the kstandarddirs patch. The KDE 4.1 issue sounds different.
Different, but related, it turns out this upstream kstandarddirs change is to blame: http://websvn.kde.org/trunk/KDE/kdelibs/kdecore/kernel/kstandarddirs.cpp?r1=819551&r2=819560 F9 build: http://koji.fedoraproject.org/koji/taskinfo?taskID=682824 Rawhide build: http://koji.fedoraproject.org/koji/taskinfo?taskID=682835
I can confirm that the ordering issue is fixed in kdelibs-4.0.5-4.fc9. Rex confirms 4.0.83-3.fc10 is good as well (/usr/libexec/kde4 is listed and in the correct order). F8 kdelibs4 build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=682865