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

[Lisandro Damián Nicanor Pérez Meyer]

I'll try to summarize my points of view on this issue as I have been 
maintaining qtchooser almost since the beginning. Please bear in mind that 
most of what I write here is with the experience gained during this time, had 
I know it when the issue arose here in the mailing list I would have tried to 
pop up then.

With my distro-packager hat on I realize the best solution would have been 
indeed using prefixed binaries, and not only for build-tools like qmake but 
also for tools needed at runtime like qdbus [0]. I remember Thiago also 
preparing patches for this, but as he expressed, it was no the idea that 
prevailed. That ship already sailed for Qt5, but we might want to revisit it 
for Qt6.

[0] Except of course if backward compatibility was assured for all of Qt5's 
qdbus life, but if I remember correctly that was not the case.

qtchooser, on the other hand, has it's pros and cons. For Qt developers the 
idea of easily choosing between different Qt builds is clearly a win. Now I 
think it could still be an interesting tool to use even if at some point the 
binaries get prefixed, qtchooser shipping the non-prefixed ones.

It has it's drawbacks, too. For example qtchooser needs to be installed in 
order for Qt4 and Qt5 to coexists without breaking a user's system. Installing 
it means that it starts to ship symlinks for tools that might not be 
installed, like for example lrelease. And I think we agree that lrelease is 
not a tool a user wants, so installing it as a dependency is a non.go. And 
after all, should we install the qt4, qt5 or both versions?

It will also mask tools that are only shipped in one Qt version, like 
qtconfig. Yes, I could simply make qtchooser not ship that symlink and make 
qtconfig's package ship it, but then I'll break developers' flows.

Multilib as it is in Debian is only for libs and headers. qtchooser's config 
files are shipped within /usr/lib/<arch triplet>/qtn/<someplace> because they 
content differs between archs, so making it arch-dependant.

Thiago was very kind to accept some patches for this to happen. 
QTCHOOSER_GLOBAL_DIR is used to select between the available conf files even 
with hierarchy.

I think the biggest issue here for us Debian are executables called at runtime 
for which no claim for backward compatibility was made. As binaries where not 
prefixed we needed to set qt4 as default to not break the user's setups (and 
here I mean the user of the apps made with Qt). Maybe in these cases the real 
solution would be simply adding the prefix *or* specifying in the docs that it 
must be called with the -qt<foo> argument, and consider a bug when that's not 
done. But as qtchooser was not really deployed in other OSs I don't know how 
practical this can be. 

Ideas are of course much welcomed. I really hope to be able to get to a conf 
someday to discuss this face-to-face, time will tell...

-- 
“I don’t think security can solve problems.
We need to teach greater respect.”
  Oslo Mayor Stang when asked whether Oslo needs greater security
  after the attacks in Norway, 07/2011.

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/28a2f52b/attachment.sig>