[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