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/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
