Thiago Macieira wrote: > packagers, like we did in the past for qtchooser (a solution designed for > distro's needs).
Hahaha, that's a good one! Qtchooser is designed completely PAST distros' needs and entirely useless for distros. What we actually asked for (and have always been shipping, and at least in Fedora, still ship for Qt 5) is suffixed binaries. What you delivered instead is wrappers that move the onus on deciding which Qt version to use from the package/tarball's build system (which is surely the best place to know which major version it needs) to the user, using a per- user-account configuration file. Sure, it is also possible to select the Qt version with a command-line argument to the qtchooser wrappers, but since the binary with the exact same name could also be an unwrapped binary, which does NOT handle that command- line argument, it is impossible to reliably use those command-line arguments in build systems. The third method, magic environment variables, is also not very suitable for some build systems. In addition, both the command-line and the environment variable methods share the problem that the names of the available Qt versions are not standardized (e.g., do they include only the one-digit major version number? the 5.x major-minor version number? the full 5.x.y version number? with or without arch suffix? etc.), making them unsuitable for build systems to use. On the other hand, the suffixed binaries, with the de-facto-standard naming convention (*-qtN, where N is the major version) that distros have been using for years, just work. Build systems only have to check for qmake-qt5 first and then fall back to qmake (and the well-designed build systems in fact already do that). (As for CMake, your shipped *Config files for Qt 5 actually find the unsuffixed binaries directly in the non-PATH directory and thus also do not need qtchooser. For Qt 4, see "well-designed build systems" above, FindQt4.cmake gets it right.) The user does not have to pick a Qt version, the software he/she is trying to build (which KNOWS what version of Qt it wants) picks the binaries with the correct suffix automatically (and if not, that software's build system is broken – mostly only an issue with stuff coming from Qt upstream, which assumes that everyone ships Qt exactly as upstream and ignores real-world distribution packaging entirely). It shall also be noted that even if one accepts the idea that the user should select a Qt version to use, that can be implemented without any wrappers such as qtchooser, by simply prepending the relevant bin directory to the PATH. (This is also the workaround we use in specfiles for broken build systems that do not understand suffixed binaries.) In other words, qtchooser does not provide any value at all to our users. Therefore, we are NOT shipping qtchooser in Fedora by default, and our qtchooser package in the online repository (package which we only ship at all due to the insistence of one individual packager – both I and the primary maintainer of Qt in Fedora have requested its removal from Fedora more than once) does NOT automatically add itself to the PATH. So, sorry, but qtchooser is exactly an example of how NOT to do things. I can only urge you to finally implement our original request of just officially adding the required -qt5 suffix to all the binaries, and to deprecate or outright drop qtchooser. Kevin Kofler _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development