[Bug 895149] Review Request: qtchooser - Qt Chooser

[bugzilla at redhat.com]

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=895149

Kevin Kofler <kevin at tigcc.ticalc.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kevin at tigcc.ticalc.org

--- Comment #1 from Kevin Kofler <kevin at tigcc.ticalc.org> ---
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