Comment 1 for bug 1176686

Hmm, this is a bit complicated. qtchooser shouldn't be installed on non-development machines, so KDE does not currently directly use it anyhow. It seems that for 13.04 some KDE package was patched to forcefully add /usr/lib/[your-arch]/qt4/bin to PATH which is why it works for most people now (but causes Qt5 to not be easily usable for KDE users since the addition is before /usr/bin).

The root problem within qtchooser itself is that it handles qdbus the same as purely development oriented binaries, so qdbus cannot be installed to /usr/bin as before, so on non-development machines qdbus is not available at all via default PATH, regardless of multi-arch or not.

One more change is that qdbus has now been split to its own qdbus-qt5 package in Debian, so it will come to saucy as well. But I believe this is currently about Qt4's qdbus usage.

So with the current forced PATH the qtchooser side of the story shouldn't affect KDE users, but it will affect if a) qtchooser is started to be used for everyone (requires configuration to be moved to a non-dev package), b) the PATH hack is removed.

I believe the options strictly related on what to do now regarding qdbus usage in KDE are:
1) Continue to use the PATH hack, whichever package it comes from, but add support for multi-arch
2) Patch KDE to use the deep paths /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/qt4/bin when calling dbus.

And regarding qtchooser itself, I'm not sure. The upstream probably hasn't considered multi-arch so far.