Bugzilla Bug 33079

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.