2015-01-20 19:59 GMT+02:00 Kevin Kofler <kevin.kof...@chello.at>: > scheme.) Debian is now using qtchooser. (But have they ever shipped a > "qmake5" to begin with?)
The original packaging used the -qt5 suffix but it was dropped [1] in favor of the recommended qtchooser before uploading the first Qt 5 version to Debian or Ubuntu. Qt 4 was first modified to use qtchooser so that both could be co-installed. [1] http://anonscm.debian.org/cgit/pkg-kde/qt/qtbase.git/commit/?id=1c9f8be04f4d30a9ea6c1bdaa6be1dbbe4b8fed5 qtchooser nowadays works adequately with fallback handling and other workarounds. Ubuntu is also shipping a patch that is not accepted by upstream [2] as we wanted to offer environment variable / parameter / default configuration free working of the "user" (developer user) tools. Upstream considers all qtchooser handled binaries as strictly development tools, so there is a different point of view there too. [2] https://codereview.qt-project.org/#/c/82702/ So yes, it's a patch upon a patch solution. It still causes confusion for random developers that happen to use command line and are not yet familiar with qtchooser. But they do learn, and a majority of at least app developers probably install the SDK / Qt Creator and are not affected. On the plus side, I like the shorter non-suffix binary names, and the fact that a default or non-default can be easily set. On the negative side, not having anything set gives a far from optimal newbie experience. Because of that for example installing the Ubuntu SDK sets Qt 5 as the default configuration for qtchooser. I don't have a strong opinion, but it needs to be all platforms or nothing. Otherwise cross-platform developers and documentation just get confused. -Timo _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
