[Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
Kevin Kofler
kevin.kofler at chello.at
Mon Jan 19 15:30:48 CET 2015
Thiago Macieira wrote:
> On Saturday 17 January 2015 23:46:58 Kevin Kofler wrote:
>> 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.
>
> Please reconsider. There's something to gain just by being compliant with
> what we standardised and recommend.
I just realized yet another showstopper that precludes supporting qtchooser
in Fedora by default: A core assumption in qtchooser's design is that the
unsuffixed binaries in the default PATH ("default binaries") all default to
the same version of Qt. But this is not how things work in Fedora: In an
effort of being as compatible with upstream as possible, we have only added
suffixes where there are actually conflicts. As a result, the "default
binary" is the one where the given binary was first introduced (except that
we do not support Qt 1 or 2 anymore, so Qt 3 is the minimum we care about).
For example, the default "qmake" is the Qt 3 one, the default "qdbus" is the
Qt 4 one, the default "qtpaths" is the Qt 5 one. The qtchooser wrapper does
not support this setup, and thus enabling it by default would be a
backwards-incompatible change and might break several Qt 3 or 4 packages.
This would have been an issue even if we had picked up qtchooser immediately
when it was introduced, because we already had this mixed setup for Qt 3 and
4 binaries. (Excluding the Qt >= 4 binaries from qtchooser wrapping entirely
would not have worked because of Qt 5.)
Kevin Kofler
More information about the Development
mailing list