Thiago Macieira wrote: > That logic is inverted. It needs to try qmake first because it might be a > more recent version, installed by a binary from the Qt Project, since we > don't rename. Any qmake-qt4 tool, if present, is an older version from the > distribution.
The only thing I promised is that if there is a Qt 4 qmake in the PATH, it WILL find it. Now if there is more than one version, which one is the preferred version is arguable. I'd argue that the distribution's Qt is always the preferred one unless the user explicitly requests something different. (And by the way, we wouldn't have this problem if you were finally shipping suffixed binaries upstream.) As for "an older version from the distribution", some "koji latest-pkg" output for you: Build Tag Built by ---------------------------------------- -------------------- ------------ qt-4.8.6-20.fc22 f22 rdieter qt-4.8.6-18.fc21 f21-updates rdieter qt-4.8.6-18.fc20 f20-updates rdieter "Older", you say? It's actually NEWER than your latest upstream release because it includes some backported patches. Now, before you claim this is easy for the legacy Qt 4, here's the data for Qt 5: Build Tag Built by ---------------------------------------- -------------------- ------------ qt5-qtbase-5.4.0-6.fc22 f22 rdieter qt5-qtbase-5.4.0-2.fc21 f21-updates rdieter qt5-qtbase-5.4.0-2.fc20 f20-updates rdieter > Renaming the tools creates other problems. We needed a compromise and > qtchooser is it. I still have not heard of a single problem that renaming the tools upstream (and thus for all downstreams) would cause. (Of course, you would actually ship BOTH the old and new name for the lifetime of Qt 5, otherwise the compatibility problems are obvious. This would not have been an issue if the rename had been done back in 5.0.0. Qt 6.0.0 will be the next opportunity to get rid of the legacy names.) > That won't happen because those applications will get written for the > official binaries from the Qt Project, which do not contain renamed tools. > Do you really think people will write software that doesn't compile with > the official version? Software on GNU/Linux often gets developed against distribution -devel packages. I definitely do that whenever possible. Do you really think that all developers of Qt-using software download your upstream binaries or build your source code themselves, when they can just "yum install qt-devel"? That said, what Qt setup is encountered of course depends on the distribution the developer(s) is/are using. > Remember: you (implicitly) agreed with the solution in 2012. I did not agree with anything at all. You brought up a discussion on a Qt Project mailing list, to which most distribution packagers are not even subscribed. You got only very limited feedback from distributors. You never bothered to approach distributors through places they follow, such as the kde-packager (at the time) mailing list (or even OUR mailing lists, or aliases such as qt-ow...@distro.example.com), at least not before the decision was made. It is only coincidence that I learned of the discussion at all, when it was already at a late stage. Assuming that all the people you did not ask agree with you just does not make any sense whatsoever. > If you unilaterally choose to deviate from it, Our intentions have been clearly announced on our mailing list, IRC channel and publicly-logged IRC meetings from day 1. By not objecting, by your own logic, you implicitly agreed to them. Kevin Kofler _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development