Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=895149 Kevin Kofler <kevin@xxxxxxxxxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kevin@xxxxxxxxxxxxxxxx --- Comment #1 from Kevin Kofler <kevin@xxxxxxxxxxxxxxxx> --- DO. NOT. WANT! This is a horribly stupid, overengineered and useless hack. Just by a cursory glance at the specfile and the code, I can find several faults with this approach, some of which are fundamental design issues, whereas others are just a result of the implementation being a non-portable quick hack. The things I noticed: * qtchooser installs all the qt* binaries as wrappers, but does not require any of the actual implementations, so build systems will think the executables are available when they're actually not. One could, theoretically, Require some virtual Provides, but that'd be bad in several ways: it'd be a circular dependency, it'd require all the binaries at once unless qtchooser gets split into many subpackages (ugh!) and there'd still be no guarantee that you get the version of the binary you actually wanted. * As you already found out, this issue also breaks PackageKit-command-not-found. * As I already explained several times, there's no sane way for a build script to reliably pick the Qt version with this system. Environment variables are not something build systems normally muck with, and the parameters are broken because they'll cause errors if the build system hits the actual binary rather than the wrapper (which it will have to be prepared for even if we ship qtchooser in Fedora, there will definitely be platforms not using it, e.g., qtchooser doesn't even support anything other than POSIX according to the comment at the beginning, even though funnily there are some #ifdef _WIN32 conditionals). * In addition, the available Qt versions depend on config files, i.e. the build system has no way to know whether they have to pass -qt=4, -qt=4.8, -qt=4.8.3, -qt=native-4.8.3 (there have also been talks about using this for cross Qt, for which there's no standard whatsoever) etc. (or the equivalent environment variable). * The parameter parsing is dumb lowest-level C-without-getopt-style and does not follow any POSIX, GNU or even Qt conventions. * If $HOME is not set, the code will attempt to use a top-level /.config directory, a bug which has caused us trouble in Qt itself too. A comment in the code ("// accept empty $HOME too") tries to explain this bug into a "feature". I'm sure there are more flaws that would become apparent if we continued further down this dead end and attempted to actually ship this junk. I do not think we want to ship this in Fedora, ever. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=d93d1mHto9&a=cc_unsubscribe _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review