Packaging Qt-based stuff
When Qt5 was near the corner a member of our team took the time to consult upstream for a sane way to allow both Qt4 and Qt5 SDKs to coexist without us distros having to reinvent the wheel choosing which tools have to be in use in each case.
After a long discussion, upstream decided to write qtchooser to be able to select between Qt4, Qt5 and even special user's cases like own or cross-platform builds.
So instead of going trough Debian's alternatives as we did with Qt3/Qt4, we will make use of this new tool.
Packaging with Qt4, Qt5 or both of them
The selection method is based on qtchooser. Take a look at it's man page for full details, but basically boils down to:
- Exporting QT_SELECT with 4, qt4, 5 or qt5 as value in debian/rules.
- Call the tool using the '-qtx' parameter, where x can be replaced with any of the options above.
We have also provided qt4-[arch-triplet] and qt5-[arch-triplet] options for special cases, in case you might need them. Beware this should not be used to build packages for the Debian archive.
Please also note that the above is not really required for Qt4. In other words your current Qt4 packages won't break if you don't do it, but we recommend doing so non the less.
Notes on using both Qt4 and Qt5 in the same source package
Please note there is no point in shipping an application built with both flavours, please use Qt5 whenever possible. This double compilation should be left only for libraries.
You can't mix Qt4 and Qt5 in the same binary, but you may provide libraries compiled against one or the other. For example, your source package foo could provide both libqt4foo1 and libqt5foo1. You need to mangle your debian/rules and/or build system accordingly to achieve this.
A good example both for upstream code allowing both styles of compilation and debian packaging is phonon. Take a look at the CMakeLists.txt files for seeing how a source can be built against both flavours and another to debian/rules to see an example of how to handle the compilation. Just bare in mind to replace $(overridden_command) with the command itself, that variable substitution comes from internal stuff from our team and you should not be using it without a very good reason. If in doubt, feel free to ask us on IRC or on the mailing lists.
Choosing the right tool at runtime
If your application needs to call a tool, like for example qdbus, masked by qtchooser then beware that by default the Qt4 version will be used. If you need to use the Qt5 version you need to use any of the methods qtchooser provides. Two simple solutions (although both with their drawbacks) are:
- Patch the source code to add -qt5 to every external Qt5 tool invocation. For example, if the code calls "moc --parameter1 --parameter2" then use "moc -qt=5 --parameter1 --parameter2".
- Replace the binary with a script that sets the environment variable QT_SELECT to qt5 and then call the binary.
A note on using Qt 5
While not strictly necessary it is highly recommended to explicitely build depend upon qtbase5-dev. All other Qt 5 development packages should get this package as a dependency, but adding it to any package's Build-Depends ensures symbols files do the right when creating shared libraries dependencies.