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

Thiago Macieira thiago.macieira at intel.com
Sun Jan 18 21:39:32 CET 2015


On Sunday 18 January 2015 15:02:21 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
> 
> 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.

Can you elaborate on what the problem was?

qdbus is an identical tool in both Qt 4 and Qt 5, modulo bugs in Qt itself. It 
shouldn't matter which one gets run.

That said, back in 2012 when we were discussing the renaming, I made the 
argument that some of our binary executables are not "build tools" but are 
instead "user applications". Those should not be installed in a private 
libexec dir, but should be global in /usr/bin and not proxied by qtchooser. 
Distros would also take care to install only one and we would take care to 
keep compatibility with Qt 4 and, if necessary, Qt 3.

That proposal was also rejected.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Development mailing list