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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
