It defines KDEDIR=/usr/kde/3.2, but since kde-env defines KDEDIRS=/usr, this overrides KDEDIR. Most apps work, but e.g. kopete fails to find it's plugins. So 49kdedir-3.2.0 should also define KDEDIRS not KDEDIR. Also see: http://www.kde.org/areas/sysadmin/fsh.php
also: http://bugs.kde.org/show_bug.cgi?id=67668
you tried running kbuildsycoca afterwards, right?
Seems like what we should do then is: remove all instances of KDEDIR Then do something like this in env.d: 31kde -> KDEDIRS="$KDEDIRS:/usr/kde/3.1" 32kde -> KDEDIRS="$KDEDIRS:/usr/kde/3.2" 99kde -> KDEDIRS="$KDEDIRS:/usr" and get rid of other instances of setting KDEDIRS in the code. What do you think?
Yeah, that's what I would do. The only problem with this setup is that kde 3.1 will be before 3.2 and so 3.1 apps will be used although you are in 3.2. But the same problem is if we reverse the order, then kde 3.2 apps will be used in kde 3.1, any idea?
The apps themselves go into /usr, so that's okay. But, kde's programs themselves are in /usr/kde/3.x Perhaps it should be set at startkde time?
The order of the libraries in ld.so.conf are significant, too.
startkde time sounds good to me
caleb: any news on this?
haven't even thought about it, :(
I found that the existence of KDEDIRS=/usr/kde/3.1 somewhere will break kde-3.2 as it will try to find incompatible components from 3.1. /usr/kde/3.2 was not in KDEDIRS at all though, only /usr and /usr/kde/3.1
The same kind of problem exists with 48kdepaths-3.2.0 vs. 49kdepaths-3.1.x, since the first bin dir in PATH determines which version of KDE's apps get run. This means you have to swap things around in /etc/env.d to change which kdm starts up...
A brief summing up: as I said in http://bugs.kde.org/show_bug.cgi?id=67668, since kde 3.0 the use of KDEDIR and KDEDIRS has been regulated by this code: From kdelibs/kdecore/kstandarddirs.cpp: QString kdedirs = readEnvPath("KDEDIRS"); if (!kdedirs.isEmpty()) { tokenize(kdedirList, kdedirs, ":"); } else { QString kdedir = readEnvPath("KDEDIR"); if (!kdedir.isEmpty()) { kdedir = KShell::tildeExpand(kdedir); kdedirList.append(kdedir); } } kdedirList.append(KDEDIR); KDEDIR is a #define in kdelibs/config.h and contains the value of --prefix (e. g. "/usr/kde/3.2") This mean that on a Gentoo system, a kde app linked against kdelibs-3.2 searches for its resources first in /usr (the value of KDEDIRS), then in /usr/kde/3.2 (brought by "kdedirList.append(KDEDIR)"), while the KDEDIR environment value is ignored. So, the current situations is optimal for KDEDIRS: apps linked to 3.2 search in /usr and /usr/kde/3.2, apps linked to 3.1 search in /usr and /usr/kde/3.1... With respect to PATH: the values in /etc/env.d would make 3.2 always before 3.1 even in a 3.1 session, but this is corrected by the line export PATH="/usr/kde/3.1/bin:${PATH}" in startkde. So the only issue is for apps started on a command line in an old kde session (the PATH coms only from /etc/env.d there), but this is not something unbearable. The problems with loading plugins are probably due to old plugins being present in /usr, otherwise I can't explain why this is not a widespread issue. In conclusion, I suggest that KDEDIRS be left as it is now, while I propose to remove KDEDIR from both /etc/env.d (remove xxkdedir-3.x.x entirely) and startkde (remove the line "export KDEDIR="/usr/kde/x.x""), to avoid confusion. btw: QTDIR is not needed, too. The only use of QTDIR and KDEDIR that I can see is when manually running ./configure for a qt/kde app. Normally kde-functions.eclass takes care of setting them when compilation is done by portage.
caleb, can you do as suggested?
It's true that QTDIR, KDEDIR only affect custom compilation. But for that they're quite useful. So perhaps we should keep them. There are scripts and apps that expect to see them set. And I think some people might be confused by them not being defined at all, rather than by them pointing to a KDE other than the one running at the moment. What's the situation in other distros? Would people new to Gentoo expect to see QTDIR, KDEDIR set in modern environments?
On this old SuSE I've got here, only QTDIR is set. IIRC debian and fedora install kde in /usr, so it does not matter there. Thinking a bit more about it, it seems reasonable to keep QTDIR. On the other hand, kde devs more or less tried to deprecate KDEDIR in favor of KDEDIRS, and right now newer kde apps use `kde-config --prefix` during compilation. So it could make sense to remove KDEDIR.
OK, then I agree to remove $KDEDIR. We just need to change kde.eclass & kde-functions.eclass not to use/set KDEDIR - trivial. We could clean the little bits of kde2 code in there, too, since we no longer have a kdelibs2 ebuild :-)
Wait, I meant that KDEDIR could be removed from /etc/env.d and from startkde, I don't know if it's safe to remove it during compilation of kde apps...
It's not only the eclasses. arts + kdelibs ebuilds have related code, too.
OK OK, sorry. Things do still use set-kdedir and friends. Slipped my mind for a moment - I was thinking about making kde configure scripts rely on kde-config exclusively, but we'd need set-kdedir for a ebuilds that aren't fullblown kde apps anyway. So we can remove it just from the environment. (BTW arts & kdelibs don't really need it: arts only writes it to the env.d file, and kdelibs merely uses the value set by set-kdedir, which is the same as $PREFIX in its case.)
so could you please fix it ;)
KDEDIRS is now limited to /usr (ie never include /usr/kde/x.y). I'm removing KDEDIR from startkde for 3.4.0_beta2. KDEDIR isn't set in env.d by KDE 3.4 and we've all agreed to remove it from 3.3 as well (env.d + startkde). Do we need new revisions of arts/kdelibs/kdebase 3.3 for this (which would depend on one another)? Kind of a pity to force a big recompile for env.d changes...
> Do we need new revisions of arts/kdelibs/kdebase 3.3 for this (which would > depend on one another)? Kind of a pity to force a big recompile for env.d > changes... I'm doing those in a couple of days. Together with the move to /usr/share/xsessions, and with a couple other fixes (see mail to kde@g.o I sent some time ago) the bump become worthy.
OK, then you'll include these changes in your new revs?
> OK, then you'll include these changes in your new revs? Yes. In the meantime I reviewed and fixed a lot of ebuilds to make sure they don't rely on KDEDIR being set... let's hope there are not many still around :)
Eventually, this has been fixed in arts-1.3.2-r1 kdelibs-3.3.2-r3 kdebase-3.3.2-r2 closing!
It seems that the ebuild for app-pda/plptools-0.12 is not fixed because it comes up with same error (also see bug 62245, http://bugs.gentoo.org/show_bug.cgi?id=62245) ================================ checking for Qt... libraries /usr/qt/3/lib, headers /usr/qt/3/include checking if Qt compiles without flags... no checking for moc... /usr/qt/3/bin/moc checking for KDE version... 3.x checking for rpath... yes checking for KDE... configure: error: in the prefix, you've chosen, are no KDE headers installed. This will fail. So, check this please and use another prefix! !!! ERROR: app-pda/plptools-0.12 failed. !!! Function src_compile, Line 35, Exitcode 1 !!! (no error message) ================================== I am currently running: kde-base/arts-1.3.2-r1 kde-base/kdelibs-3.3.2-r9 kde-base/kdebase-3.3.2-r2 and x11-libs/qt-3.3.4-r3 all tame, stable stuff. Gregorio, would you mind please fixing this ebuild, too? -- Regards, Mick
Thanks for noticing, I suggested a fix in bug 62245. I'm not touching the ebuilds currently in portage as they don't compile anyway at the moment, I'll leave them to their maintainers.
