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

[Lisandro Damián Nicanor Pérez Meyer]

On Sunday 18 January 2015 12:39:32 Thiago Macieira wrote:
> 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?

Sur! It was discovered by [0] which happen to be QTBUG-36524.

[0] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737095>
 
> 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.

Correct! But that as long as they are the same tool, read below.

> 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.

And again, correct. And if I remember correctly when you proposed that you 
also asked if there was going to be commitment to keep qt5's qdbus backward 
compatible with qt4's one and my memory tells me no commitment was agreed upon 
(I would be very happy if proven wrong).

If I'm wrong then simply unmasking qdbus with qtchooser should be enough. 
/usr/bin/qdbus should be provided by the default version (qt4's one in our 
case) and we might even let qt5-qdbus depend upon it's qt4 version, so 
packages depending on it would get both for the time being.

If I'm *not* wrong then I have no other choice but to tell qt5-apps' 
maintainers to patch their software to call qdbus with the -qt5 parameter. And 
we can't even upstream those patches because on platforms other than Linux 
there is no qtchooser available, and most of the tools will fail saying a 
wrong parameter has been issued. So we have no other option than to keep a 
delta from upstream.


-- 
Videogames do not influence kids. I mean, if Pac-Man influenced our
generation, we would all be jumping in dark rooms, chomping magic pills
and listening to electronic repeating music.
  Kristian Wilson, Nintendo Inc. 1989

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150118/ab190a2f/attachment.sig>