[Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)

[Kevin Kofler]

Lisandro Damián Nicanor Pérez Meyer wrote:
> No, there's also qdbus for instance. We in Debian had some problems when
> users managed to get a qt4 program using qt5's qdbus by setting
> qtchooser's default at qt5. The good side of this: it turned out to be a
> bug in qt5's qdbus which got fixed and then it simply worked, but if at
> some point qt4's and qt5's version of qdbus behave differently then
> chances are that we are going to see more bugs :)

This kind of issues is exactly why Fedora does NOT use qtchooser for the 
distro Qt and strongly recommends against its use. Your packaged software in 
Debian now behaves differently depending on the user's system configuration, 
a disaster for reliability and reproducibility. I don't understand how a 
major distribution like Debian managed to decide to adopt such a flawed 
setup (but then again, that same distribution also invented the even more 
flawed "alternatives" hack…).

> I don't remeber if there are more executables in the same position as
> qdbus (ie, called at runtime) but as long as we have Qt4 as default (as we
> do by using qtchooser) more of this problems might arise.

At least Qt Assistant can also be invoked by programs. In future Qt 
versions, qtpaths (which is new in Qt 5) will also become a problem.

> Now if there is a workaround for this I would like to know it, as it will
> sure be handy in the near future.

Drop qtchooser (it just does not work), rename the conflicting binaries 
instead, using a scriptlet like this:
http://pkgs.fedoraproject.org/cgit/qt5-qtbase.git/tree/qt5-qtbase.spec#n461

And then help us get this fixed upstream for future versions of Qt (if not 
5.5, then at least 6.0, whenever that time will come).

        Kevin Kofler